kernel.git/drivers/gpu/drm/i915/intel_dp.c, branch linux-3.16.y

drm/i915/edp: Get the Panel Power Off timestamp after panel is off

2018-02-13T18:42:04Z

commit cbacf02e7796fea02e5c6e46c90ed7cbe9e6f2c0 upstream. Kernel stores the time in jiffies at which the eDP panel is turned off. This should be obtained after the panel is off (after the wait_panel_off). When we next attempt to turn the panel on, we use the difference between the timestamp at which we want to turn the panel on and timestamp at which panel was turned off to ensure that this is equal to panel power cycle delay and if not we wait for the remaining time. Not waiting for the panel power cycle delay can cause the panel to not turn on giving rise to AUX timeouts for the attempted AUX transactions. v2: * Separate lines for bugzilla (Jani Nikula) * Suggested by tag (Daniel Vetter) Cc: Daniel Vetter Cc: Jani Nikula Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101518 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101144 Suggested-by: Daniel Vetter Signed-off-by: Manasi Navare Reviewed-by: Daniel Vetter Reviewed-by: Jani Nikula Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/1507135706-17147-1-git-send-email-manasi.d.navare@intel.com [bwh: Backported to 3.16: We really do use jiffies here, and the field in struct intel_dp has a different name] Signed-off-by: Ben Hutchings

drm/i915/hsw: Fix workaround for server AUX channel clock divisor

2015-06-11T10:24:58Z

commit e058c945e03a629c99606452a6931f632dd28903 upstream. According to the HSW b-spec we need to try clock divisors of 63 and 72, each 3 or more times, when attempting DP AUX channel communication on a server chipset. This actually wasn't happening due to a short-circuit that only checked the DP_AUX_CH_CTL_DONE bit in status rather than checking that the operation was done and that DP_AUX_CH_CTL_TIME_OUT_ERROR was not set. [v2] Implemented alternate solution suggested by Jani Nikula. Signed-off-by: Jim Bride Signed-off-by: Jani Nikula Signed-off-by: Luis Henriques

drm/i915/dp: there is no audio on port A

2015-05-20T12:26:09Z

commit 9fcb1704d1d51b12e2f03c78bca013d0cbbb7c98 upstream. The eDP port A register on PCH split platforms has a slightly different register layout from the other ports, with bit 6 being either alternate scrambler reset or reserved, depending on the generation. Our misinterpretation of the bit as audio has lead to warning. Fix this by not enabling audio on port A, since none of our platforms support audio on port A anyway. v2: DDI doesn't have audio on port A either (Sivakumar Thulasimani) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89958 Reported-and-tested-by: Chris Bainbridge Reviewed-by: Sivakumar Thulasimani Signed-off-by: Jani Nikula [ luis: backported to 3.16: adjusted context ] Signed-off-by: Luis Henriques

drm/i915/dp: only use training pattern 3 on platforms that support it

2015-01-05T09:51:09Z

commit 7809a61176b385ebb3299ea43c58b1bb31ffb8c0 upstream. Ivybridge + 30" monitor prints a drm error on every modeset, since IVB doesn't support DP3 we should even bother trying to use it. This regression has been introduced in commit 06ea66b6bb445043dc25a9626254d5c130093199 Author: Todd Previte Date: Mon Jan 20 10:19:39 2014 -0700 drm/i915: Enable 5.4Ghz (HBR2) link rate for Displayport 1.2-capable devices Reported-by: Dave Airlie Reference: http://mid.gmane.org/1414566170-9868-1-git-send-email-airlied@gmail.com Cc: Todd Previte Reviewed-by: Ville Syrjälä Signed-off-by: Jani Nikula Cc: Ben Hutchings [ luis: backported to 3.16: - use dev instead of dev_priv in IS_HASWELL() and INTEL_INFO() ] Signed-off-by: Luis Henriques

drm/i915: Do a dummy DPCD read before the actual read

2014-11-13T11:48:47Z

commit f6a1906674005377b64ee5431c1418077c1b2425 upstream. Sometimes we seem to get utter garbage from DPCD reads. The resulting buffer is filled with the same byte, and the operation completed without errors. My HP ZR24w monitor seems particularly susceptible to this problem once it's gone into a sleep mode. The issue seems to happen only for the first AUX message that wakes the sink up. But as the first AUX read we often do is the DPCD receiver cap it does wreak a bit of havoc with subsequent link training etc. when the receiver cap bw/lane/etc. information is garbage. A sufficient workaround seems to be to perform a single byte dummy read before reading the actual data. I suppose that just wakes up the sink sufficiently and we can just throw away the returned data in case it's crap. DP_DPCD_REV seems like a sufficiently safe location to read here. Signed-off-by: Ville Syrjälä Reviewed-by: Todd Previte Signed-off-by: Jani Nikula Signed-off-by: Luis Henriques

drm/i915: don't try to retrain a DP link on an inactive CRTC

2014-10-05T20:40:54Z

commit 1a125d8a2c22b11741fc47d4ffcf7a5ffa044dd3 upstream. Atm we may retrain the DP link even if the CRTC is inactive through HPD work->intel_dp_check_link_status(). This in turn can lock up the PHY (at least on BYT), since the DP port is disabled. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81948 Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman

Revert "drm/i915: reverse dp link param selection, prefer fast over wide again"

2014-07-14T21:16:54Z

This reverts commit 38aecea0ccbb909d635619cba22f1891e589b434. This breaks Haswell Thinkpad + Lenovo dock in SST mode with a HDMI monitor attached. Before this we can 1920x1200 mode, after this we only ever get 1024x768, and a lot of deferring. This didn't revert clean, but this should be fine. bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1117008 Cc: stable@vger.kernel.org # v3.15 Signed-off-by: Dave Airlie Signed-off-by: Daniel Vetter

drm/i915/vlv: T12 eDP panel timing enforcement during reboot

2014-07-09T07:52:14Z

The panel power sequencer on vlv doesn't appear to accept changes to its T12 power down duration during warm reboots. This change forces a delay for warm reboots to the T12 panel timing as defined in the VBT table for the connected panel. Ver2: removed redundant pr_crit(), commented magic value for pp_div_reg Ver3: moved SYS_RESTART check earlier, new name for pp_div. Ver4: Minor issue changes Ver5: Move registration of reboot notifier to edp_connector_init, Added warning comment to handler about lack of PM notification. Signed-off-by: Clint Taylor Reviewed-by: Paulo Zanoni Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter

Merge commit '9e9a928eed8796a0a1aaed7e0b676db86ba84594' into drm-next

2014-06-05T10:28:59Z

Merge drm-fixes into drm-next. Both i915 and radeon need this done for later patches. Conflicts: drivers/gpu/drm/drm_crtc_helper.c drivers/gpu/drm/i915/i915_drv.h drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/i915_gem_execbuffer.c drivers/gpu/drm/i915/i915_gem_gtt.c

drm: convert crtc and connection_mutex to ww_mutex (v5)

2014-06-04T23:54:33Z

For atomic, it will be quite necessary to not need to care so much about locking order. And 'state' gives us a convenient place to stash a ww_ctx for any sort of update that needs to grab multiple crtc locks. Because we will want to eventually make locking even more fine grained (giving locks to planes, connectors, etc), split out drm_modeset_lock and drm_modeset_acquire_ctx to track acquired locks. Atomic will use this to keep track of which locks have been acquired in a transaction. v1: original v2: remove a few things not needed until atomic, for now v3: update for v3 of connection_mutex patch.. v4: squash in docbook v5: doc tweaks/fixes Signed-off-by: Rob Clark Reviewed-by: Daniel Vetter Signed-off-by: Dave Airlie