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 (file)
index 0000000..830f76d
--- /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 <cpaul@redhat.com>
+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 <cpaul@redhat.com>
+
+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 <cpaul@redhat.com>
+Reviewed-by: Jerome Glisse <jglisse@redhat.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 (file)
index 0000000..5214fb8
--- /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 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..5214fb8f7b707a2fcabc3d58c79a1d4e4b309715 100644 (file)
--- 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 c80e8e717e05315a6bbe881e6d78f56217257ec7..2a252eb7d6f7a9ec1676a7983235d62b290dc792 100644 (file)
--- 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 (file)
index 0000000..bb10352
--- /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