[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