On Sun, 2016-11-13 at 11:39 +0100, Daniel Vetter wrote:
> On Fri, Nov 11, 2016 at 10:21:39PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 07, 2016 at 04:27:30PM -0800, Dhinakaran Pandiyan wrote:
> > > Hotplugging a monitor in DP MST configuration triggers short pulses.
> > > Although the short pulse handling path ends up in the MST hotplug function,
> > > we do not perform a detect before sending the hotplug uvent. This leads to
> > > the connector status not being updated when the userspace calls
> > > DRM_IOCTL_MODE_GETCONNECTOR.
> > >
> > > So, let's call the connector function ->detect() to update the connector
> > > status before sending the uevent.
> > >
> > > v2: Update connector status inside mode_config mutex (Ville)
> > >
> > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@xxxxxxxxx>
> >
> > quick comments from me on irc:
> >
> > <danvet> dhnkrn, really tricky I think
> > <danvet> dhnkrn, also feels wrong from an entire design pov
> > <danvet> I'd expect the topology manager could tell us from which exact downstream port the short pulse came
> > <danvet> which means we should be able to get at that connector without taking the global lock
> > <danvet> i.e. at least avoid the for_each_connector
> > <danvet> on the detect itself, I need to think
> > <danvet> but we might need to essentially postpone the ->detect work to the hotplug worker
> > <danvet> except that it's not a direct hpd from our chip
> > <danvet> but a downstream one
> > <danvet> this is going to be fun
> > <dhnkrn> Hmm .. Does updating the connector status need the lock or is it the detect() ?
> > <danvet> yup
> > <danvet> and we might need to do additional dpcd transactions (e.g. for load detect probing on downstream ports)
> > <danvet> or at least edid reads
> > <danvet> both recurse back into dp mst helper code like ville said
> > <danvet> dhnkrn, so instead of doing the detect work from the hotplug code
> > <danvet> put them on some list
> > <danvet> need to be careful in case they are already there
> > <danvet> list only protected with dedicated lock
> > <danvet> then launch the hpd worker
> > <danvet> and walk that list from there, with the mode_config.mutex to do the full-on probe
> > <danvet> we can't call ->detect from dig_port_work, and walking the entire connector list in there is also not a good idea imo
> > <danvet> dhnkrn, but that's just my preliminary analysis from like 10 minutes of thinking and checking what ville raised
> > <danvet> needs more thought probably
> > <danvet> dhnkrn, to clarify your question: both connector->status and calling ->detect need mode_config.mutex
> > <danvet> that mutex is what protects output probe state<Vtec234> ccr: i might have udev configured incorrectly then
> >
> > Cheers, Daniel
> > > ---
> > > drivers/gpu/drm/i915/intel_dp_mst.c | 22 +++++++++++++++++++++-
> > > 1 file changed, 21 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > index 3ffbd69..8e36a96 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > @@ -492,8 +492,28 @@ static void intel_dp_mst_hotplug(struct drm_dp_mst_topology_mgr *mgr)
> > > struct intel_dp *intel_dp = container_of(mgr, struct intel_dp, mst_mgr);
> > > struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > > struct drm_device *dev = intel_dig_port->base.base.dev;
> > > + struct intel_connector *intel_connector;
> > > + bool changed = false;
> > > + enum drm_connector_status old_status;
> > > + struct drm_mode_config *mode_config = &dev->mode_config;
> > > +
> > > + mutex_lock(&mode_config->mutex);
> > > + for_each_intel_connector(dev, intel_connector) {
> > > + struct drm_connector *connector = &(intel_connector->base);
> > > +
> > > + if (intel_connector->mst_port != intel_dp)
> > > + continue;
> > > +
> > > + old_status = connector->status;
> > > + connector->status = connector->funcs->detect(connector, false);
> > > +
> > > + if (old_status != connector->status)
> > > + changed = true;
> > > + }
> > > + mutex_unlock(&mode_config->mutex);
> > >
> > > - drm_kms_helper_hotplug_event(dev);
>
> I just realized that this call here will call down into the fbdev helper,
> which already does the above ->detect calls. At least if there's no
> compositor running. So I wonder why the deadlock ville pointed out isn't
> blowing up already ...
> -Daniel
>
You are right, that call sequence does end up taking the
mode_config.mutex lock recursively. Are you referring to CI results for
this patch?
-DK
> > > + if (changed)
> > > + drm_kms_helper_hotplug_event(dev);
> > > }
> > >
> > > static const struct drm_dp_mst_topology_cbs mst_cbs = {
> > > --
> > > 2.7.4
> > >
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
