[Intel-gfx] [PATCH] drm: Don't race connector registration
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
@@ -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.
Software Engineer, Intel Corporation
More information about the Intel-gfx