[Intel-gfx] [PATCH v2] drm/i915/dp: Update connector status for DP MST hotplugs

[Daniel Vetter]

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 at intel.com>

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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch