Re: [Intel-gfx] [PATCH 3/3] drm/i915: Implement Link Rate fallback on Link training failure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 29, 2016 at 11:30:33PM -0800, Manasi Navare wrote:
> If link training at a link rate optimal for a particular
> mode fails during modeset's atomic commit phase, then we
> let the modeset complete and then retry. We save the link rate
> value at which link training failed, update the link status property
> to "BAD" and use a lower link rate to prune the modes. It will redo
> the modeset on the current mode at lower link rate or if the current
> mode gets pruned due to lower link constraints then, it will send a
> hotplug uevent for userspace to handle it.
> 
> This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
> 4.3.1.6.
> 
> v9:
> * Use the trimmed max values of link rate/lane count based on
> link train fallback (Daniel Vetter)
> v8:
> * Set link_status to BAD first and then call mode_valid (Jani Nikula)
> v7:
> Remove the redundant variable in previous patch itself
> v6:
> * Obtain link rate index from fallback_link_rate using
> the helper intel_dp_link_rate_index (Jani Nikula)
> * Include fallback within intel_dp_start_link_train (Jani Nikula)
> v5:
> * Move set link status to drm core (Daniel Vetter, Jani Nikula)
> v4:
> * Add fallback support for non DDI platforms too
> * Set connector->link status inside set_link_status function
> (Jani Nikula)
> v3:
> * Set link status property to BAd unconditionally (Jani Nikula)
> * Dont use two separate variables link_train_failed and link_status
> to indicate same thing (Jani Nikula)
> v2:
> * Squashed a few patches (Jani Nikula)
> 
> Acked-by: Tony Cheng <tony.cheng@xxxxxxx>
> Acked-by: Harry Wentland <Harry.wentland@xxxxxxx>
> Cc: Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx>
> Cc: Daniel Vetter <daniel.vetter@xxxxxxxxx>
> Cc: Ville Syrjala <ville.syrjala@xxxxxxxxxxxxxxx>
> Signed-off-by: Manasi Navare <manasi.d.navare@xxxxxxxxx>
> ---
>  drivers/gpu/drm/i915/intel_dp.c               | 44 +++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/intel_dp_link_training.c | 25 +++++++++++++--
>  drivers/gpu/drm/i915/intel_drv.h              |  3 ++
>  3 files changed, 70 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index bc1268c..a50b6cd 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4435,6 +4435,8 @@ static bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
>  		intel_dp->compliance_test_active = 0;
>  		intel_dp->compliance_test_type = 0;
>  		intel_dp->compliance_test_data = 0;
> +		intel_dp->fallback_link_rate = 0;
> +		intel_dp->fallback_lane_count = 0;

Hm, I thought we agreed on irc to just track the max link rate/lane count
at all times, instead of fallback values that sometimes are valid and
sometimes reset to 0.

Also, resetting to 0 here is wrong, since this is not the long-pulse hpd
handler. That probably also explains why you need the hack below, but not
sure.

>  
>  		if (intel_dp->is_mst) {
>  			DRM_DEBUG_KMS("MST device may have disappeared %d vs %d\n",
> @@ -4526,6 +4528,13 @@ static bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
>  	DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
>  		      connector->base.id, connector->name);
>  
> +	/* If this is a retry due to link training failure
> +	 * then do no do a full detect
> +	 */
> +	if (status == connector_status_connected &&
> +	    intel_dp->fallback_lane_count)
> +		return status;

That sounds very wrong. Why do we need it?

> +
>  	/* If full detect is not performed yet, do a full detect */
>  	if (!intel_dp->detect_done)
>  		status = intel_dp_long_pulse(intel_dp->attached_connector);
> @@ -5690,6 +5699,37 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
>  	return false;
>  }
>  
> +static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
> +{
> +	struct intel_connector *intel_connector;
> +	struct drm_connector *connector;
> +	struct drm_display_mode *mode;
> +	bool verbose_prune = true;
> +
> +	intel_connector = container_of(work, typeof(*intel_connector),
> +				       modeset_retry_work);
> +	connector = &intel_connector->base;
> +	DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> +		      connector->name);
> +
> +	/* Grab the locks before changing connector property*/
> +	mutex_lock(&connector->dev->mode_config.mutex);
> +	/* Set connector link status to BAD and send a Uevent to notify
> +	 * userspace to do a modeset.
> +	 */
> +	drm_mode_connector_set_link_status_property(connector,
> +						    DRM_MODE_LINK_STATUS_BAD);
> +	list_for_each_entry(mode, &connector->modes, head) {
> +		mode->status = intel_dp_mode_valid(connector,
> +						   mode);
> +	}
> +	drm_mode_prune_invalid(connector->dev, &connector->modes,
> +			       verbose_prune);

This call to drm_mode_prune_invalid is probably just to paper over a bug
in SNA - SNA violates the hotplug handling uabi by not unconditionally
reprobing. Inconsistently paper over that bug in the kernel is not good,
userspace interfaces need to be well defined. Please remove this call and
test with either UXA or -modesetting until SNA is fixed.
-Daniel

> +	mutex_unlock(&connector->dev->mode_config.mutex);
> +	/* Send Hotplug uevent so userspace can reprobe */
> +	drm_kms_helper_hotplug_event(connector->dev);
> +}
> +
>  bool
>  intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
>  			struct intel_connector *intel_connector)
> @@ -5702,6 +5742,10 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
>  	enum port port = intel_dig_port->port;
>  	int type;
>  
> +	/* Initialize the work for modeset in case of link train failure */
> +	INIT_WORK(&intel_connector->modeset_retry_work,
> +		  intel_dp_modeset_retry_work_fn);
> +
>  	if (WARN(intel_dig_port->max_lanes < 1,
>  		 "Not enough lanes (%d) for DP on port %c\n",
>  		 intel_dig_port->max_lanes, port_name(port)))
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 0048b52..cb28788 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -313,6 +313,27 @@ void intel_dp_stop_link_train(struct intel_dp *intel_dp)
>  void
>  intel_dp_start_link_train(struct intel_dp *intel_dp)
>  {
> -	intel_dp_link_training_clock_recovery(intel_dp);
> -	intel_dp_link_training_channel_equalization(intel_dp);
> +	struct intel_connector *intel_connector = intel_dp->attached_connector;
> +
> +	if (!intel_dp_link_training_clock_recovery(intel_dp))
> +		goto failure_handling;
> +	if (!intel_dp_link_training_channel_equalization(intel_dp))
> +		goto failure_handling;
> +
> +	/* Reset the Link Train Values */
> +	DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane count = %d",
> +		      intel_dp->link_rate, intel_dp->lane_count);
> +	intel_dp->fallback_link_rate = 0;
> +	intel_dp->fallback_lane_count = 0;
> +	return;
> +
> + failure_handling:
> +	DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane count = %d",
> +		      intel_dp->link_rate, intel_dp->lane_count);
> +	if (!intel_dp_get_link_train_fallback_values(intel_dp,
> +						     intel_dp->link_rate,
> +						     intel_dp->lane_count))
> +		/* Schedule a Hotplug Uevent to userspace to start modeset */
> +		schedule_work(&intel_connector->modeset_retry_work);
> +	return;
>  }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index 2da3b40..d95a51e 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -315,6 +315,9 @@ struct intel_connector {
>  	void *port; /* store this opaque as its illegal to dereference it */
>  
>  	struct intel_dp *mst_port;
> +
> +	/* Work struct to schedule a uevent on link train failure */
> +	struct work_struct modeset_retry_work;
>  };
>  
>  struct dpll {
> -- 
> 1.9.1
> 
> _______________________________________________
> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux