[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1465507015-23052-5-git-send-email-kamal@canonical.com>
Date: Thu, 9 Jun 2016 14:13:33 -0700
From: Kamal Mostafa <kamal@...onical.com>
To: linux-kernel@...r.kernel.org, stable@...r.kernel.org,
kernel-team@...ts.ubuntu.com
Cc: Lyude <cpaul@...hat.com>, Daniel Vetter <daniel.vetter@...ll.ch>,
Kamal Mostafa <kamal@...onical.com>
Subject: [PATCH 4.2.y-ckt 004/206] drm/i915: Call intel_dp_mst_resume() before resuming displays
4.2.8-ckt12 -stable review patch. If anyone has any objections, please let me know.
---8<------------------------------------------------------------
From: Lyude <cpaul@...hat.com>
commit a16b7658f4e0d4aec9bc3e75a5f0cc3f7a3a0422 upstream.
Since we need MST devices ready before we try to resume displays,
calling this after intel_display_resume() can result in some issues with
various laptop docks where the monitor won't turn back on after
suspending the system.
This order was originally changed in
commit e7d6f7d70829 ("drm/i915: resume MST after reading back hw state")
In order to fix some unclaimed register errors, however the actual cause
of those has since been fixed.
Signed-off-by: Lyude <cpaul@...hat.com>
[danvet: Resolve conflicts with locking changes.]
Signed-off-by: Daniel Vetter <daniel.vetter@...ll.ch>
[ kamal: backport to 4.2-stable: context ]
Signed-off-by: Kamal Mostafa <kamal@...onical.com>
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9d42aeb..2188b7f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -762,12 +762,12 @@ static int i915_drm_resume(struct drm_device *dev)
dev_priv->display.hpd_irq_setup(dev);
spin_unlock_irq(&dev_priv->irq_lock);
+ intel_dp_mst_resume(dev);
+
drm_modeset_lock_all(dev);
intel_modeset_setup_hw_state(dev, true);
drm_modeset_unlock_all(dev);
- intel_dp_mst_resume(dev);
-
/*
* ... but also need to make sure that hotplug processing
* doesn't cause havoc. Like in the driver load code we don't
--
2.7.4
Powered by blists - more mailing lists