From: Greg Kroah-Hartman Date: Tue, 15 Sep 2015 21:25:15 +0000 (-0700) Subject: 4.1-stable patches X-Git-Tag: v3.10.89~35 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=691f94335fa1817307bdfd2ed49cc5249e5a2d41;p=thirdparty%2Fkernel%2Fstable-queue.git 4.1-stable patches added patches: drm-i915-apply-the-pci_d0-d3-hibernation-workaround-everywhere-on-pre-gen6.patch drm-i915-check-dp-link-status-on-long-hpd-too.patch drm-radeon-don-t-link-train-displayport-on-hpd-until-we-get-the-dpcd.patch --- diff --git a/queue-4.1/drm-i915-apply-the-pci_d0-d3-hibernation-workaround-everywhere-on-pre-gen6.patch b/queue-4.1/drm-i915-apply-the-pci_d0-d3-hibernation-workaround-everywhere-on-pre-gen6.patch new file mode 100644 index 00000000000..b425285dab9 --- /dev/null +++ b/queue-4.1/drm-i915-apply-the-pci_d0-d3-hibernation-workaround-everywhere-on-pre-gen6.patch @@ -0,0 +1,79 @@ +From 54875571bbfde00fc63741715c531cbb5246c3b2 Mon Sep 17 00:00:00 2001 +From: Imre Deak +Date: Tue, 30 Jun 2015 17:06:47 +0300 +Subject: drm/i915: apply the PCI_D0/D3 hibernation workaround everywhere on pre GEN6 + +From: Imre Deak + +commit 54875571bbfde00fc63741715c531cbb5246c3b2 upstream. + +commit da2bc1b9db3351addd293e5b82757efe1f77ed1d +Author: Imre Deak +Date: Thu Oct 23 19:23:26 2014 +0300 + + drm/i915: add poweroff_late handler + +introduced a regression on old platforms during hibernation. A workaround was +added in + +commit ab3be73fa7b43f4c3648ce29b5fd649ea54d3adb +Author: Imre Deak +Date: Mon Mar 2 13:04:41 2015 +0200 + + drm/i915: gen4: work around hang during hibernation + +using an explicit blacklist for the GENs/BIOS vendors where the issue was +reported. Later there we had reports of the same failure on platforms not on +this list. + +To my best knowledge the correct thing to do is still to put the device to PCI +D3 state during hibernation, see [1] and [2] for the reasons. This also aligns +with our future plans to unify more the runtime and system suspend/resume +paths. Since an exact blacklist seems to be impractical (multiple GENs and +BIOS vendors are affected) apply the workaround on everything pre GEN6. + +[1] http://lists.freedesktop.org/archives/intel-gfx/2015-February/060710.html +[2] https://lkml.org/lkml/2015/6/22/274 + +Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=95061 +Reported-by: Ilya Tumaykin +Reported-by: Dirk Griesbach +Reported-by: Pavel Machek +Reported-by: Mikko Rapeli +Tested-by: Mikko Rapeli +Reported-by: Paul Bolle +Signed-off-by: Imre Deak +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_drv.c | 15 +++++++++------ + 1 file changed, 9 insertions(+), 6 deletions(-) + +--- a/drivers/gpu/drm/i915/i915_drv.c ++++ b/drivers/gpu/drm/i915/i915_drv.c +@@ -647,15 +647,18 @@ static int i915_drm_suspend_late(struct + + pci_disable_device(drm_dev->pdev); + /* +- * During hibernation on some GEN4 platforms the BIOS may try to access ++ * During hibernation on some platforms the BIOS may try to access + * the device even though it's already in D3 and hang the machine. So + * leave the device in D0 on those platforms and hope the BIOS will +- * power down the device properly. Platforms where this was seen: +- * Lenovo Thinkpad X301, X61s ++ * power down the device properly. The issue was seen on multiple old ++ * GENs with different BIOS vendors, so having an explicit blacklist ++ * is inpractical; apply the workaround on everything pre GEN6. The ++ * platforms where the issue was seen: ++ * Lenovo Thinkpad X301, X61s, X60, T60, X41 ++ * Fujitsu FSC S7110 ++ * Acer Aspire 1830T + */ +- if (!(hibernation && +- drm_dev->pdev->subsystem_vendor == PCI_VENDOR_ID_LENOVO && +- INTEL_INFO(dev_priv)->gen == 4)) ++ if (!(hibernation && INTEL_INFO(dev_priv)->gen < 6)) + pci_set_power_state(drm_dev->pdev, PCI_D3hot); + + return 0; diff --git a/queue-4.1/drm-i915-check-dp-link-status-on-long-hpd-too.patch b/queue-4.1/drm-i915-check-dp-link-status-on-long-hpd-too.patch new file mode 100644 index 00000000000..fd5d79d6856 --- /dev/null +++ b/queue-4.1/drm-i915-check-dp-link-status-on-long-hpd-too.patch @@ -0,0 +1,75 @@ +From d14e7b6d1d8747826cb900db852351c550e00fdd Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= +Date: Thu, 20 Aug 2015 19:37:29 +0300 +Subject: drm/i915: Check DP link status on long hpd too +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= + +commit d14e7b6d1d8747826cb900db852351c550e00fdd upstream. + +We are no longer checkling the DP link status on long hpd. We used to do +that from the .hot_plug() handler, but it was removed when MST got +introduced. + +If there's no userspace we now fail to retrain the link if the sink +power is toggled (or cable yanked and replugged), meaning the user is +left staring at a blank screen. With the retraining put back that should +be fixed. + +Also remove the leftover comment that referred to the old retraining +from .hot_plug(). + +Fixes a regression introduced in: +commit 0e32b39ceed665bfa4a77a4bc307b6652b991632 +Author: Dave Airlie +Date: Fri May 2 14:02:48 2014 +1000 + + drm/i915: add DP 1.2 MST support (v0.7) + +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89453 +Tested-by: Palmer Dabbelt +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91407 +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89461 +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89594 +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85641 +Cc: Dave Airlie +Signed-off-by: Ville Syrjälä +Reviewed-by: Daniel Vetter +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_dp.c | 11 +++++------ + 1 file changed, 5 insertions(+), 6 deletions(-) + +--- a/drivers/gpu/drm/i915/intel_dp.c ++++ b/drivers/gpu/drm/i915/intel_dp.c +@@ -4691,9 +4691,12 @@ intel_dp_hpd_pulse(struct intel_digital_ + + intel_dp_probe_oui(intel_dp); + +- if (!intel_dp_probe_mst(intel_dp)) ++ if (!intel_dp_probe_mst(intel_dp)) { ++ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL); ++ intel_dp_check_link_status(intel_dp); ++ drm_modeset_unlock(&dev->mode_config.connection_mutex); + goto mst_fail; +- ++ } + } else { + if (intel_dp->is_mst) { + if (intel_dp_check_mst_status(intel_dp) == -EINVAL) +@@ -4701,10 +4704,6 @@ intel_dp_hpd_pulse(struct intel_digital_ + } + + if (!intel_dp->is_mst) { +- /* +- * we'll check the link status via the normal hot plug path later - +- * but for short hpds we should check it now +- */ + drm_modeset_lock(&dev->mode_config.connection_mutex, NULL); + intel_dp_check_link_status(intel_dp); + drm_modeset_unlock(&dev->mode_config.connection_mutex); diff --git a/queue-4.1/drm-radeon-don-t-link-train-displayport-on-hpd-until-we-get-the-dpcd.patch b/queue-4.1/drm-radeon-don-t-link-train-displayport-on-hpd-until-we-get-the-dpcd.patch new file mode 100644 index 00000000000..fee261a2ad3 --- /dev/null +++ b/queue-4.1/drm-radeon-don-t-link-train-displayport-on-hpd-until-we-get-the-dpcd.patch @@ -0,0 +1,75 @@ +From 924f92bf12bfbef3662619e3ed24a1cea7c1cbcd Mon Sep 17 00:00:00 2001 +From: Stephen Chandler Paul +Date: Fri, 21 Aug 2015 14:16:12 -0400 +Subject: DRM - radeon: Don't link train DisplayPort on HPD until we get the dpcd + +From: Stephen Chandler Paul + +commit 924f92bf12bfbef3662619e3ed24a1cea7c1cbcd upstream. + +Most of the time this isn't an issue since hotplugging an adaptor will +trigger a crtc mode change which in turn, causes the driver to probe +every DisplayPort for a dpcd. However, in cases where hotplugging +doesn't cause a mode change (specifically when one unplugs a monitor +from a DisplayPort connector, then plugs that same monitor back in +seconds later on the same port without any other monitors connected), we +never probe for the dpcd before starting the initial link training. What +happens from there looks like this: + + - GPU has only one monitor connected. It's connected via + DisplayPort, and does not go through an adaptor of any sort. + + - User unplugs DisplayPort connector from GPU. + + - Change in HPD is detected by the driver, we probe every + DisplayPort for a possible connection. + + - Probe the port the user originally had the monitor connected + on for it's dpcd. This fails, and we clear the first (and only + the first) byte of the dpcd to indicate we no longer have a + dpcd for this port. + + - User plugs the previously disconnected monitor back into the + same DisplayPort. + + - radeon_connector_hotplug() is called before everyone else, + and tries to handle the link training. Since only the first + byte of the dpcd is zeroed, the driver is able to complete + link training but does so against the wrong dpcd, causing it + to initialize the link with the wrong settings. + + - Display stays blank (usually), dpcd is probed after the + initial link training, and the driver prints no obvious + messages to the log. + +In theory, since only one byte of the dpcd is chopped off (specifically, +the byte that contains the revision information for DisplayPort), it's +not entirely impossible that this bug may not show on certain monitors. +For instance, the only reason this bug was visible on my ASUS PB238 +monitor was due to the fact that this monitor using the enhanced framing +symbol sequence, the flag for which is ignored if the radeon driver +thinks that the DisplayPort version is below 1.1. + +Signed-off-by: Stephen Chandler Paul +Reviewed-by: Jerome Glisse +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/radeon/radeon_connectors.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/gpu/drm/radeon/radeon_connectors.c ++++ b/drivers/gpu/drm/radeon/radeon_connectors.c +@@ -95,6 +95,11 @@ void radeon_connector_hotplug(struct drm + if (!radeon_hpd_sense(rdev, radeon_connector->hpd.hpd)) { + drm_helper_connector_dpms(connector, DRM_MODE_DPMS_OFF); + } else if (radeon_dp_needs_link_train(radeon_connector)) { ++ /* Don't try to start link training before we ++ * have the dpcd */ ++ if (!radeon_dp_getdpcd(radeon_connector)) ++ return; ++ + /* set it to OFF so that drm_helper_connector_dpms() + * won't return immediately since the current state + * is ON at this point.