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);
> + 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
