[Intel-gfx] [PATCH] drm: Don't race connector registration

Daniel Vetter daniel at ffwll.ch
Mon Jan 30 09:12:26 UTC 2017

On Thu, Jan 26, 2017 at 12:34:29PM -0800, Dave Hansen wrote:
> On 01/25/2017 07:38 AM, Daniel Vetter wrote:
> > On Wed, Jan 25, 2017 at 07:20:45AM -0800, Dave Hansen wrote:
> >> On 01/24/2017 10:21 PM, Daniel Vetter wrote:
> >>> Hi Dave,
> >>>
> >>> Still waiting for your testing results on this one here ...
> >>
> >> It's definitely stable with that patch applied.  No more crashes.
> >>
> >> But, it's also definitely having difficulty re-probing to find the
> >> monitor that's attached to the dock in some cases.  Whatever is going on
> >> isn't fixed by poking it with xrandr.
> > 
> > Is this new? When exactly does this happen? Does the mst sink connector no
> > longer show up, or is the connected/disconnected status all wrong?
> It's hard to say whether it's new or not.  I *think* it worked better
> before, but it also crashed pretty often, so it's hard to say.

Ok, I guess that's good enough to push at least the crash fix forward.

> And, yeah, I think it just gets the connected status wrong.  The
> connector is still there.

Hm, I thought I replied here but I didn't:
- Is this just after boot (and then the connector is stuck forever), or
  starts to happen after suspend/resume, or some other system change like
  that? Or do they just crop up eventually?

- Does this only happen once the connector is destroyed? Please trace
  intel_dp_destroy_mst_connector with something like:

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
index 38e3ca2f6f18..24ac2d1ce3ad 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -502,6 +502,8 @@ static void intel_dp_destroy_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
+	printk("mst connector getting destroyed: %s\n", connector->name);
 	/* need to nuke the connector */

- If it's not that then something in intel_dp_mst_detect (well, it's
  helper implementation drm_dp_mst_detect_port) is probably going wrong.

Cheers, Daniel
Daniel Vetter
Software Engineer, Intel Corporation

More information about the Intel-gfx mailing list