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@xxxxxxxxxx> > > > > 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@xxxxxxxxxx> > > Makes sense, so Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > And Cc: stable@xxxxxxxxxxxxxxx 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
