[Intel-gfx] [PATCH] drm/i915: resume MST after reading back hw state

Daniel Vetter daniel at ffwll.ch
Mon Dec 8 01:51:39 PST 2014


On Mon, Dec 08, 2014 at 10:44:54AM +0100, Daniel Vetter wrote:
> On Mon, Dec 08, 2014 at 01:23:37PM +1000, Dave Airlie wrote:
> > From: Dave Airlie <airlied at redhat.com>
> > 
> > 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 <airlied at redhat.com>
> 
> Makes sense, so Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> 
> And Cc: stable at vger.kernel.org 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?

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the Intel-gfx mailing list