--- /dev/null
+From 54875571bbfde00fc63741715c531cbb5246c3b2 Mon Sep 17 00:00:00 2001
+From: Imre Deak <imre.deak@intel.com>
+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 <imre.deak@intel.com>
+
+commit 54875571bbfde00fc63741715c531cbb5246c3b2 upstream.
+
+commit da2bc1b9db3351addd293e5b82757efe1f77ed1d
+Author: Imre Deak <imre.deak@intel.com>
+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 <imre.deak@intel.com>
+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 <itumaykin@gmail.com>
+Reported-by: Dirk Griesbach <spamthis@freenet.de>
+Reported-by: Pavel Machek <pavel@ucw.cz>
+Reported-by: Mikko Rapeli <mikko.rapeli@iki.fi>
+Tested-by: Mikko Rapeli <mikko.rapeli@iki.fi>
+Reported-by: Paul Bolle <pebolle@tiscali.nl>
+Signed-off-by: Imre Deak <imre.deak@intel.com>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -683,15 +683,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;
--- /dev/null
+From d14e7b6d1d8747826cb900db852351c550e00fdd Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+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?= <ville.syrjala@linux.intel.com>
+
+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 <airlied@redhat.com>
+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 <palmer@dabbelt.com>
+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 <airlied@redhat.com>
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -4987,9 +4987,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)
+@@ -4997,10 +5000,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);
--- /dev/null
+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
+@@ -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.
projects / thirdparty / kernel / stable-queue.git / commitdiff
