From: Greg Kroah-Hartman Date: Tue, 15 Sep 2015 21:25:04 +0000 (-0700) Subject: 3.10-stable patches X-Git-Tag: v3.10.89~37 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=830e5ebb014392771eab5559480ba8d812c332a0;p=thirdparty%2Fkernel%2Fstable-queue.git 3.10-stable patches added patches: drm-radeon-don-t-link-train-displayport-on-hpd-until-we-get-the-dpcd.patch --- diff --git a/queue-3.10/drm-radeon-don-t-link-train-displayport-on-hpd-until-we-get-the-dpcd.patch b/queue-3.10/drm-radeon-don-t-link-train-displayport-on-hpd-until-we-get-the-dpcd.patch new file mode 100644 index 00000000000..830f76dc97f --- /dev/null +++ b/queue-3.10/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 +@@ -78,6 +78,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. diff --git a/queue-3.10/series b/queue-3.10/series new file mode 100644 index 00000000000..5214fb8f7b7 --- /dev/null +++ b/queue-3.10/series @@ -0,0 +1 @@ +drm-radeon-don-t-link-train-displayport-on-hpd-until-we-get-the-dpcd.patch diff --git a/queue-3.14/series b/queue-3.14/series index e69de29bb2d..5214fb8f7b7 100644 --- a/queue-3.14/series +++ b/queue-3.14/series @@ -0,0 +1 @@ +drm-radeon-don-t-link-train-displayport-on-hpd-until-we-get-the-dpcd.patch diff --git a/queue-4.1/series b/queue-4.1/series index c80e8e717e0..2a252eb7d6f 100644 --- a/queue-4.1/series +++ b/queue-4.1/series @@ -2,3 +2,6 @@ x86-ldt-make-modify_ldt-synchronous.patch x86-ldt-correct-ldt-access-in-single-stepping-logic.patch x86-ldt-correct-fpu-emulation-access-to-ldt.patch x86-ldt-further-fix-fpu-emulation.patch +drm-radeon-don-t-link-train-displayport-on-hpd-until-we-get-the-dpcd.patch +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 diff --git a/queue-4.2/series b/queue-4.2/series new file mode 100644 index 00000000000..bb1035221b8 --- /dev/null +++ b/queue-4.2/series @@ -0,0 +1,3 @@ +drm-radeon-don-t-link-train-displayport-on-hpd-until-we-get-the-dpcd.patch +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