- 27 Jan, 2013 1 commit
-
-
Paulo Zanoni authored
Instead of setting it at the beginning of haswell_crtc_mode_set, let's set it at the beginning of intel_crtc_mode_set. When intel_crt_mode_set calls drm_vblank_pre_modeset we already need to have the transcoder_edp correctly set, because eventually drm_vblank_pre_modeset calls functions that call i915_pipe_enabled from i915_irq.c, which will read PIPECONF(cpu_transcoder). This is a bug that affects us since we added support for TRANSCODER_EDP, but I was only able to see the problem after suspending a machine with the power well disabled (got an "unclaimed register" error. 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>
-
- 26 Jan, 2013 8 commits
-
-
Paulo Zanoni authored
We should avoid touching registers that are on the power down well when we don't need to, because if we touch these registers when the power well is disabled we'll get tons of "unclaimed register" messages. This commit fixes some of these messages. Signed-off-by:
-
Paulo Zanoni authored
The current code was wrong in many different ways, so this is a full rewrite. We don't have "different power wells for different parts of the GPU", we have a single power well, but we have multiple registers that can be used to request enabling/disabling the power well. So let's be a good citizen and only use the register we're suppose to use, except when we're loading the driver, where we clear the request made by the BIOS. If any of the registers is requesting the power well to be enabled, it will be enabled. If none of the registers is requesting the power well to be enabled, it will be disabled. For now we're just forcing the power well to be enabled, but in the next commits we'll change this. V2: - Remove debug messages that could be misleading due to possible race conditions with KVMr, Debug and BIOS. - Don't wait on disabling: after a conversaion with a hardware engineer we discovered that the "restriction" on bit 31 is just for the "enable" case, and we don't even need to wait on the "disable" case. Signed-off-by: -
Ville Syrjälä authored
Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
SR01 needs to be touched to disable VGA on non-UMS setups too. So the sequencer registers need to include the appripriate offset on VLV. Signed-off-by:
-
Ville Syrjälä authored
When passing the DP/HDMI/SDVO registers to the encoder init functions, include the VLV specific offset in the value. v2: Resolved conflicts w/ VLV SDVO elimination Signed-off-by:
-
Ville Syrjälä authored
Don't call intel_sdvo_init() for VLV. Preserve the same behaviour as when intel_sdvo_init() would have returned false. Signed-off-by:
-
Ville Syrjälä authored
Instead of using ADPA/VLV_ADPA/PCH_ADPA in various parts of intel_crt code, just use adpa_reg which always contains the correct value for the platform. Signed-off-by:
-
Ville Syrjälä authored
v2: Dropped the clock gating registers Signed-off-by:
-
- 24 Jan, 2013 24 commits
-
-
Ville Syrjälä authored
This will cause display registers to include the correct offset on VLV. Signed-off-by:
-
Ville Syrjälä authored
GPIO/GMBUS registers must be offset on VLV, so simply adjust gpio_mmio_base to include the correct offset. Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Instead of 0x18xxxx use (VLV_DISPLAY_BASE + xxxx). Signed-off-by:
-
Ville Syrjälä authored
Instead of 0x18xxxx use (VLV_DISPLAY_BASE + xxxx). Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
CURSIZE is not present on VLV, so it was left out, as were the IVB specific cursor B registers. Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Add an optional offset to intel_device_info, which will added to most display register offsets. Signed-off-by:
-
Ville Syrjälä authored
Use intel_dig_port->port rather than intel_dp->output_reg. Signed-off-by:
-
Ville Syrjälä authored
Use intel_dig_port->port rather than intel_hdmi->sdvox_erg. Signed-off-by:
-
Paulo Zanoni authored
Because the register does not exist in gen5+. This patch solves "unclaimed register" messages on Haswell after suspend/resume. Signed-off-by:
-
- 22 Jan, 2013 6 commits
-
-
Daniel Vetter authored
commit 09153000 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Dec 12 14:06:44 2012 +0100 drm/i915: rework locking for intel_dpio|sbi_read|write reworked the locking around sbi_read/write functions for 3.8-fixes. But commit dde86e2d Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Sat Dec 1 12:04:25 2012 -0200 drm/i915: add lpt_init_pch_refcl Added new use-cases in the -next tree which has not been updated in the merge. Fix it up. Reported-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
-
Wang Xingchao authored
ELD info should be updated dynamically according to hot plug event. For haswell chip, clear/set the eld valid bit and output enable bit from callback intel_disable/eanble_ddi(). Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
Wang Xingchao <xingchao.wang@intel.com> Signed-off-by:
-
Mika Kuoppala authored
When machine was rebooted or module was reloaded, gem_hw_init() set last_seqno to be identical to next_seqno. This lead to situation that waits for first ever request always passed immediately regardless if it was actually executed. Use gem_set_seqno() to be consistent how hw is initialized on init, wrap and on resume. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Jani Nikula authored
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44156Reported-by:
Alan Zimmerman <alan.zimm@gmail.com> Signed-off-by:
-
Jani Nikula authored
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=31522#c35 [Note: There are more than one broken setups in the bug. This fixes one.] Reported-by:
Martins <andrissr@inbox.lv> Signed-off-by:
-
Jani Nikula authored
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59628Reported-by:
Roland Gruber <post@rolandgruber.de> Signed-off-by:
-
- 21 Jan, 2013 1 commit
-
-
Daniel Vetter authored
Damien Lespiau wondered how race the gpu reset/hang detection code is against concurrent gpu resets/hang detections or combinations thereof. Luckily the single work item is guranteed to never run concurrently, so reset handling is already single-threaded. Hence we only have to worry about concurrent hang detections, or a hang detection firing off while we're still processing an older gpu reset request. Due to the new mechanism of setting the reset in progress flag and the ordering guaranteed by the schedule_work function there's nothing to do but add a comment explaining why we're safe. The only thing I've noticed is that we still try to reset the gpu now, even when it is declared terminally wedged. Add a check for that to avoid continous warnings about failed resets, in case the hangcheck timer ever gets stuck. Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
