summaryrefslogtreecommitdiff
path: root/drivers/gpu (follow)
Commit message (Collapse)AuthorAge
...
| | * | | drm: extract dp link bw helpersDaniel Vetter2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm/i915: use the new dp train delay helpersDaniel Vetter2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Only really required for dp 1.2. I've hoped this would help with some link training woes I'm fighting, but alas those are only dp 1.1 devices. Also move a comment that went misplaced in the recent refactorings to the right spot again. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm: extract dp link train delay functions from radeonDaniel Vetter2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This requires a few changes since that dpcd value is above the range currently cached by radeon. I've check the dp specs, and above 0xf there's a big gap and nothing that looks like we should cache it while a given device is plugged in. It's also the same value that i915.ko uses. Hence extend the various dpcd arrays in the radeon driver, use proper symbolic constants where applicable (one place overallocated the dpcd array to 25 bytes). Then also drop the rd_interval cache - radeon_dp_link_train_init re-reads the dpcd block, so the values we'll consume in train_cr and train_ce will always be fresh. To avoid needless diff-churn, #define the old size of dpcd as the new one and keep it around. v2: Alex Deucher noticed one place where I've forgotten to replace 8 with DP_RECEIVER_CAP_SIZE. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm: extract helpers to compute new training values from sink requestDaniel Vetter2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Safe for the minor difference that the intel versions get an offset into the link_status as an argument, both are the same again. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm: dp helper: extract drm_dp_clock_recovery_okDaniel Vetter2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | radeon and intel use the exact same definition. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Dave Airlie <airlied@gmail.com> v2: Kill 2 more helpers in intel_dp.c that I've missed. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm: dp helper: extract drm_dp_channel_eq_okDaniel Vetter2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | radeon and intel use the exact same definition. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm: rename drm_dp_i2c_helper.c to drm_dp_helper.cDaniel Vetter2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I want to move some dp link training helpers into this place, so in the future this won't be just about i2c any longer. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm/i915: remove unused mem_block struct definitionMika Kuoppala2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm/i915: Move cached EDID to intel_connectorJani Nikula2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the cached EDID from intel_dp and intel_lvds_connector to intel_connector. Unify cached EDID handling for LVDS and eDP, in preparation for adding more generic EDID caching later. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm/i915: Do not free the passed EDID in intel_connector_update_modes()Jani Nikula2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The caller, not intel_connector_update_modes(), should free the edid. This improves the reusability of intel_connector_update_modes(). Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm/i915: Move the fixed mode to intel_panelJani Nikula2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pave the way for sharing some logic between eDP and LVDS. Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm/i915: Create generic intel_panel for LVDS and eDPJani Nikula2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a generic struct intel_panel for sharing a data structure and code between eDP and LVDS panels. Add the new struct to intel_connector so that later on we can have generic EDID and mode reading functions with EDID caching that transparently fallback to fixed mode when EDID is not available. Add intel_panel as a dummy first, and move data (such as the mentioned fixed mode) to it in later patches. Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Fixup tiny conflict in intel_dp_destroy.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm/i915/dp: Initialize eDP fixed mode in intel_dp_initJani Nikula2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since we do EDID caching in intel_dp_init, we can do the fixed mode initialization there too. This should not change the functionality apart from initializing fixed mode earlier. Particularly retain the behaviour of only falling back to VBT if EDID is not available to not regress commit 47f0eb2234a2a1c790825393bbaccfadf82463d3 Author: Keith Packard <keithp@keithp.com> Date: Mon Sep 19 14:33:26 2011 -0700 drm/i915: Only use VBT panel mode on eDP if no EDID is found Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm/i915/lvds: Move some connector specific info across from the encoderJani Nikula2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As there is 1:1 mapping between encoder and connector for the LVDS, the goal is to simply reduce the amount of noise within the connector functions, i.e. we split the encoder/connector for LVDS as best we can and try to only operate on the LVDS connector from the connector funcs and the LVDS encoder form the encoder funcs. Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm/i915: Backlight setup requires connector so pass it as parameterJani Nikula2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Get rid of saved int_lvds_connector and int_edp_connector in drm_i915_private. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm/i915/lvds: Move the acpi_lid_notifier from drm_i915_private to the connectorJani Nikula2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm/i915/lvds: Introduce intel_lvds_connectorJani Nikula2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a local structure to move LVDS specific information away from the drm_i915_private and onto the LVDS connector. Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm/i915/lvds: Rename intel_lvds to intel_lvds_encoderJani Nikula2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for introducing intel_lvds_connector to move some of the LVDS specific storage away from drm_i915_private, first rename the encoder to avoid potential confusion. Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | Merge tag 'v3.7-rc2' into drm-intel-next-queuedDaniel Vetter2012-10-22
| | |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linux 3.7-rc2 Backmerge to solve two ugly conflicts: - uapi. We've already added new ioctl definitions for -next. Do I need to say more? - wc support gtt ptes. We've had to revert this for snb+ for 3.7 and also fix a few other things in the code. Now we know how to make it work on snb+, but to avoid losing the other fixes do the backmerge first before re-enabling wc gtt ptes on snb+. And a few other minor things, among them git getting confused in intel_dp.c and seemingly causing a conflict out of nothing ... Conflicts: drivers/gpu/drm/i915/i915_reg.h drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_dp.c drivers/gpu/drm/i915/intel_modes.c include/drm/i915_drm.h Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: Don't program DSPCLK_GATE_D twice on IVB and VLVDamien Lespiau2012-10-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We were programming register 0x42020 twice on those platforms. Once should be enough. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: Program DSPCLK_GATE_D only once on IronlakeDamien Lespiau2012-10-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the consolidated registers, it appears that we're setting the same bis several times. Let's just collect the bits we want to set and program it once. v2: More cleanup. Also program 0x42004 and 0x45000 for FBC on non mobile platforms (Paulo Zanoni) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Undo the functional change as discussed on irc.] Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: Consolidate ILK_DSPCLK_GATE and PCH_DSPCLK_GATEDamien Lespiau2012-10-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Register 0x42020 was defined twice under the names PCH_DSPCLK_GATE_D and ILK_DSPCLK_GATE. This patch consolidate the 2 sets of defines in one. The transforms done are: PCH_DSPCLK_GATE_D -> ILK_DSPCLK_GATE_D ILK_DSPCLK_GATE -> ILK_DSPCLK_GATE_D DPARBUNIT_CLOCK_GATE_DISABLE -> ILK_DPARBUNIT_CLOCK_GATE_DISABLE ILK_DPARB_CLK_GATE -> ILK_DPARBUNIT_CLOCK_GATE_DISABLE DPFDUNIT_CLOCK_GATE_DISABLE -> ILK_DPFDUNIT_CLOCK_GATE_DISABLE ILK_DPFD_CLK_GATE -> ILK_DPFDUNIT_CLOCK_GATE_DISABLE ILK_CLK_FBC -> ILK_DPFDUNIT_CLOCK_GATE_DISABLE DPFCRUNIT_CLOCK_GATE_DISABLE -> ILK_DPFCRUNIT_CLOCK_GATE_DISABLE ILK_DPFC_DIS1 -> ILK_DPFCRUNIT_CLOCK_GATE_DISABLE DPFCUNIT_CLOCK_GATE_DISABLE -> ILK_DPFCUNIT_CLOCK_GATE_DISABLE ILK_DPFC_DIS2 -> ILK_DPFCUNIT_CLOCK_GATE_DISABLE We have a VHRUNIT_CLOCK_GATE_DISABLE define for the pre-ILK DSPCLK_GATE_D. Even if the same bit is used in ILK_DSPCLK_GATE_D, other bits in the register change, so I went with re-defining it, well more precisely rename IVB_VRHUNIT_CLK_GATE, which is not specific to IVB+. So: IVB_VRHUNIT_CLK_GATE -> ILK_VHRUNIT_CLOCK_GATE_DISABLE VHRUNIT_CLOCK_GATE_DISABLE -> ILK_VHRUNIT_CLOCK_GATE_DISABLE (ILK+ code) This commit is only a renaming commit, further commits will clean up the logic. v2: Rename bit 5 and 7 to _ENABLE as setting them to 1 enables clock gating on their respective units, contrary to all of the other bits (Paulo Zanoni) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: unconditionally use mt forcewake on hsw/ivbDaniel Vetter2012-10-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Single-threaded forcewake was only used on some early pre-production ivybridge machines, all the latest ones should use mt forcewake. And we already assume this in other places of the code (e.g. DERRMR support in the ddx, or the latest intel_gt_reset patch to reset any lingering forcewake references left behind by the bios), so don't bother here, too. Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: set the correct function pointers for Haswell DPPaulo Zanoni2012-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the final remaining piece of Haswell DP enablement. After this patch, just calling intel_dp_init on any port will make DP work. We still do not do this because we're currently initializing HDMI on all the ports, so if we replace intel_hdmi_init with intel_dp_init, we will break HDMI, and we can't call both because they share the same registers. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: implement Haswell DP link train sequencePaulo Zanoni2012-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previous patch "drm/i915: add basic Haswell DP link train bits" implemented the basic structure to set the voltage levels and training patterns. This patch adds the higher-level bits that are part of the mode set sequence and hot plug. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: fix Haswell DP M/N registersPaulo Zanoni2012-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have to write the correct values inside intel_dp_set_m_n and then prevent these values from being overwritten later. V2: Unconfuse double negation. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: add DP support to intel_ddi_disable_portPaulo Zanoni2012-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Just a missing register. There is no problem to run this code when the output is HDMI. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: add DP support to intel_ddi_mode_setPaulo Zanoni2012-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: add DP support to intel_enable_ddiPaulo Zanoni2012-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We should only write the DDI_BUF_CTL at this point for HDMI/DVI. For DP we need to do this earlier, and the values written to the register are also different. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: add DP support to intel_ddi_get_hw_statePaulo Zanoni2012-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: add DP support to intel_ddi_get_encoder_portPaulo Zanoni2012-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: fix DP AUX register definitions on HaswellPaulo Zanoni2012-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old rule that the AUX registers are just an offset (+4 and +10) from output_reg is not true anymore, since output_reg in on the CPU and some AUX regs are on the PCH. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: use the existing #defines as spotted by Damien Lespiau.] Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: Clear FORCEWAKE when taking over from BIOSChris Wilson2012-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some BIOSes may forcibly suspend RC6 during their operation which trigger a warning as we find the hardware in a perplexing state upon first use. So far that appears to be the worst symptom as fortuituously we use the same values as the BIOS for programming the FORCEWAKE register. Reported-by: Oleksij Rempel <bug-track@fisher-privat.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: don't save/restor ADPA for kmsDaniel Vetter2012-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We now no longer rely on this. This is step 1 on a long journey to rid us of the save/restore madness, which tends to lightly paper over many issues, and cause tons of bad things itself ... Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: satisfy Paulo's ocd and drop the needless braces.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915/crt: explicitly set up HOTPLUG_BITS on resumeDaniel Vetter2012-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... instead of relying on the register save/restore madness to do this. To extract a bit of code call drm_mode_config_reset both on resume and boot-up and move the hw state frobbing from the crt_init to the ->reset callback. The crt connector is the only one with a ->reset callback, hence we can easily do this. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915/crt: don't set HOTPLUG bits on !PCHDaniel Vetter2012-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... since they don't apply to pre-pch platforms and could actually be harmful. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: don't save/restore HWS_PGA reg for kmsDaniel Vetter2012-10-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We already do that as part of the ringbuffer re-setup at resume time. Furthermore the register offset has moved on gen6+ around quite a bit, and on ilk/gm45 we also need to restore the HWS reg for the bsd ring, not just the render ring. So again in kms mode this is only confusing a best, hence don't bother. v2: Fixup logic, noticed by Paulo Zanoni. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: don't save/restore irq regs for kmsDaniel Vetter2012-10-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We already call drm_irq_install/uninstall at the right time, which will set up the irq registers with the correct values (through the preinstall hooks). For kms this is at best harmless, in the worst case we get an interrupt when we don't really expect it. v2: Fixup the logic, noticed by Paulo Zanoni. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: don't save/restore DP regs for kmsDaniel Vetter2012-10-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We completely compute these anew in each modeset, hence we don't rely on them containing anything valid after resume. To avoid breaking any ums setup due to reordering of the reads/writes simply don't reorder anything, but bracket the reads/writes into if (!kms) conditionals. More churn, but safer. v2: Fixup the logic, noticed by Paulo Zanoni. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: use TU_SIZE macro at intel_dp_set_m_nPaulo Zanoni2012-10-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Much simpler and looks more like the M/N code inside intel_display.c. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: add basic Haswell DP link train bitsPaulo Zanoni2012-10-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the DP register was used for everything. On Haswell, it was split into DDI_BUF_CTL (which is the new intel_dp->DP register) and DP_TP_CTL. The logic behind this patch is based on a patch written by Shobhit Kumar, but the way the code was written is very different. Credits-to: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Fixup the logic error spotted by Jani Nikula.] Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: add DP support to intel_ddi_pll_mode_setPaulo Zanoni2012-10-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: add intel_ddi_set_pipe_settingsPaulo Zanoni2012-10-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In theory, all the DDI pipe settings should be set here, including timing and M/N registers. For now, let's just set the DP MSA attributes. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: fixed up the unused typo in a #define, spotted by Jani Nikula.] Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: add DP support to intel_ddi_enable_pipe_funcPaulo Zanoni2012-10-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: Document the multi-threaded FORCEWAKE bitsChris Wilson2012-10-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No functional change, but reserves 0x2 for use by userspace. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: Allow DRM_ROOT_ONLY|DRM_MASTER to submit privileged batchbuffersChris Wilson2012-10-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the introduction of per-process GTT space, the hardware designers thought it wise to also limit the ability to write to MMIO space to only a "secure" batch buffer. The ability to rewrite registers is the only way to program the hardware to perform certain operations like scanline waits (required for tear-free windowed updates). So we either have a choice of adding an interface to perform those synchronized updates inside the kernel, or we permit certain processes the ability to write to the "safe" registers from within its command stream. This patch exposes the ability to submit a SECURE batch buffer to DRM_ROOT_ONLY|DRM_MASTER processes. v2: Haswell split up bit8 into a ppgtt bit (still bit8) and a security bit (bit 13, accidentally not set). Also add a comment explaining why secure batches need a global gtt binding. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) [danvet: added hsw fixup.] Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: move hpd handling to (ibx|cpt)_irq_handlerDaniel Vetter2012-10-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Somehow this was left out in the refactoring that introduced the pch handlers. Avoids a hotplug_mask special case in the ilk_irq_handler. Noticed while hunting down the pch hotplug bits. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: Add rc6vids to debugfsBen Widawsky2012-10-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CC: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: Workaround to bump rc6 voltage to 450Ben Widawsky2012-10-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BIOS should be setting the minimum voltage for rc6 to be 450mV. Old or buggy BIOSen may not be doing this, so we correct it for them. Ideally customers should update the BIOS as only it would know the optimal values for the platform, so we leave that fact as a DRM_ERROR for the user to see. Unfortunately this isn't fixing any of the issues it was targeted to fix, but it is documented that we must do it. CC: Jesse Barnes <jbarnes@virtuousgeek.org> CC: Matt Turner <mattst88@gmail.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: bikeshedded loglevel of the "your bios is broken message" to debug.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | drm/i915: Extract PCU communicationBen Widawsky2012-10-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a special mechanism for communicating with the PCU already being used for the ring frequency stuff. As we'll be needing this for other commands, extract it now to make future code less error prone and the current code more reusable. I'm not entirely sure if this code matches 1:1 with the previous code behaviorally. Functionally however, it should be the same. CC: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Fixup compile fail reported by Wu Fengguang.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.25.1) at 2026-08-10 11:38:10 +0000