drm/i915: resume MST after reading back hw state
Subsystems (2)
Dave Airlie
maintainerPATCH 1/1 drm/i915: resume MST after reading back hw state
From: Dave Airlie <[email protected]>
Otherwise the MST resume paths can hit DPMS paths which hit state checker paths, which hit WARN_ON, because the state checker is inconsistent with the hw.
This fixes a bunch of WARN_ON's on resume after
undocking.
--- drivers/gpu/drm/i915/i915_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/i915/i915_drv.c +2 -1
@@ -706,11 +706,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
Signature · 6 lines
2.1.0 _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoted 11 lines · Dave Airlie
From: Dave Airlie <[email protected]>
Otherwise the MST resume paths can hit DPMS paths which hit state checker paths, which hit
WARN_ON, because the state checker is inconsistent with the hw.This fixes a bunch of WARN_ON's on resume after
undocking.Signed-off-by Dave Airlie <[email protected]>
Makes sense, so Reviewed-by: Daniel Vetter <[email protected]>
And Cc: [email protected] when Jani picks it up.
While reading around I've noticed though that we might miss dp mst changes after resume:
- intel_dp_mst_resume checks for can_mst, so will skip if we didn't plug in an mst thing before suspend.
- drm_helper_hpd_irq_event only does the locked detect dance and doesn't do the unlocked mst dance we do before calling down into ->detect callbacks.
So I think if we plug in an mst dock while suspended and then resume we'll miss the hotplug in the kernel. Or do I miss something? -Daniel
Signature · 7 lines
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoted 25 lines · Daniel Vetter
Quoted 11 lines · Dave Airlie
From: Dave Airlie <[email protected]>
Otherwise the MST resume paths can hit DPMS paths which hit state checker paths, which hit
WARN_ON, because the state checker is inconsistent with the hw.This fixes a bunch of WARN_ON's on resume after
undocking.Signed-off-by Dave Airlie <[email protected]>Makes sense, so Reviewed-by: Daniel Vetter <[email protected]>
And Cc: [email protected] when Jani picks it up.
While reading around I've noticed though that we might miss dp mst changes after resume:
-intel_dp_mst_resumechecks forcan_mst, so will skip if we didn't plug in an mst thing before suspend.
-drm_helper_hpd_irq_eventonly does the locked detect dance and doesn't do the unlocked mst dance we do before calling down into ->detect callbacks.
Quoted 2 lines
So I think if we plug in an mst dock while suspended and then resume we'll miss the hotplug in the kernel. Or do I miss something?
Aside: On some ports/platforms hpd pins don't work until hpd interrupts are enabled. So maybe we should take the full reprobe out of intel_dp_mst_resume anyway and replace drm_helper_hpd_irq_event with a call to schedule our async hpd worker with all port bits set? -Daniel
Signature · 7 lines
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoted 8 lines · Daniel Vetter
Quoted 7 lines · Dave Airlie
From: Dave Airlie <[email protected]>
Otherwise the MST resume paths can hit DPMS paths which hit state checker paths, which hit
WARN_ON, because the state checker is inconsistent with the hw.
Quoted 6 lines
Quoted 4 lines
This fixes a bunch of WARN_ON's on resume after
undocking.Signed-off-by Dave Airlie <[email protected]>Makes sense, so Reviewed-by: Daniel Vetter <[email protected]>
Pushed to drm-intel-next-fixes, thanks for the patch and review.
BR,
Jani.
Quoted 18 lines
And Cc: [email protected] when Jani picks it up.
While reading around I've noticed though that we might miss dp mst changes after resume:
-intel_dp_mst_resumechecks forcan_mst, so will skip if we didn't plug in an mst thing before suspend.
-drm_helper_hpd_irq_eventonly does the locked detect dance and doesn't do the unlocked mst dance we do before calling down into ->detect callbacks.So I think if we plug in an mst dock while suspended and then resume we'll miss the hotplug in the kernel. Or do I miss something? -Daniel
Signature · 3 lines
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Signature · 5 lines
Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
-------------------------------------Summary-------------------------------------
Platform Delta drm-intel-nightly Series Applied
PNV 364/364 364/364
ILK +3 362/366 365/366
SNB 448/450 448/450 IVB 497/498 497/498 BYT 289/289 289/289 HSW 563/564 563/564 BDW 417/417 417/417 -------------------------------------Detailed------------------------------------- Platform Test drm-intel-nightly Series Applied ILK igt_kms_flip_nonblocking-read DMESG_WARN(1, M26)PASS(3, M26M37) PASS(1, M37) ILK igt_kms_setmode_invalid-clone-exclusive-crtc DMESG_WARN(1, M26)PASS(3, M26M37) PASS(1, M37) ILK igt_kms_flip_flip-vs-rmfb-interruptible DMESG_WARN(1, M26)PASS(3, M26M37) PASS(1, M37)
Note: You need to pay more attention to line start with '*'
_______________________________________________
Intel-gfx mailing list [email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx