Re: [Intel-gfx] [PATCH] drm/i915/dp: Reset link params on connector disconnect

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Thu, Jun 04, 2020 at 11:52:24AM -0700, Manasi Navare wrote:
> On Thu, Jun 04, 2020 at 09:38:19PM +0300, Ville Syrjälä wrote:
> > On Thu, Jun 04, 2020 at 11:35:30AM -0700, Manasi Navare wrote:
> > > On Thu, Jun 04, 2020 at 06:25:43PM +0300, Ville Syrjälä wrote:
> > > > On Wed, Jun 03, 2020 at 05:23:59PM -0700, Manasi Navare wrote:
> > > > > We have noticed that when link training fails the panel
> > > > > sends a long pulse indicating connector disconnect. In this case
> > > > > we need to reset the link parameters instead of continuing
> > > > > to use the fallback parameters since else this long pulse
> > > > > by the panel followed by a modeset request which was triggered by the userspace
> > > > > before getting the connector status as disconnected, will
> > > > > result into a modeset now using lower link rate/lane count values.
> > > > > 
> > > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1385
> > > > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> > > > > ---
> > > > >  drivers/gpu/drm/i915/display/intel_dp.c | 28 +++++++++++++++++--------
> > > > >  1 file changed, 19 insertions(+), 9 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > index 55fda074c0ad..f7af372647dd 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > @@ -6111,6 +6111,18 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
> > > > >  	intel_dp->edid_quirks = 0;
> > > > >  }
> > > > >  
> > > > > +static void
> > > > > +intel_dp_reset_link_params(struct intel_dp *intel_dp)
> > > > > +{
> > > > > +	/* Initial max link lane count */
> > > > > +	intel_dp->max_link_lane_count = intel_dp_max_common_lane_count(intel_dp);
> > > > > +
> > > > > +	/* Initial max link rate */
> > > > > +	intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> > > > > +
> > > > > +	intel_dp->reset_link_params = false;
> > > > > +}
> > > > > +
> > > > >  static int
> > > > >  intel_dp_detect(struct drm_connector *connector,
> > > > >  		struct drm_modeset_acquire_ctx *ctx,
> > > > > @@ -6139,6 +6151,11 @@ intel_dp_detect(struct drm_connector *connector,
> > > > >  		memset(&intel_dp->compliance, 0, sizeof(intel_dp->compliance));
> > > > >  		memset(intel_dp->dsc_dpcd, 0, sizeof(intel_dp->dsc_dpcd));
> > > > >  
> > > > > +		/*Reset the immutable VRR Capable property */
> > > > > +		drm_connector_set_vrr_capable_property(connector,
> > > > > +						       false);
> > > > > +		intel_dp_reset_link_params(intel_dp);
> > > > > +
> > > > 
> > > > Why would we care what those are when the sink is disconnected?
> > > 
> > > We are noticing this happen in case the panel send this long pulse indicating
> > > status change to disconnected, while the modeset was already triggered by userspace
> > > in this case IGT, so the modeset continues right after i915_hotplug_work_fn
> > > so we need to reset all params which fixes the bug mentioned.
> > 
> > Why did the link params get out of whack before hpd in the first place?
> >
> 
> Most of the failures, we see the link training fails due to AUX timeouts and then link params fallback to lower values
> Then we get this hpd, in this case if we dont reset the param to max values, prev triggered modeset continues
> with fallback values but since connector probe doesnt happen again through IGT, it tries the same mode
> with fallback values and return encoder config failure.

If the link training failed then clearly the sink didn't like us anymore
anyway. So feels like resetting these here is just shifting some race
window around a bit, but it could still fail if the sink still doesn't
like us.

Would be good if someone was able to figure out why the sink goes bad in
the first place.

> 
> So after reseting the params, the modeset happens with original values and that time link training passes.
> This is seen in all kms_atomic_transitions IGT tests
> 
> Manasi
>  
> > > 
> > > Manasi
> > > 
> > > > 
> > > > >  		if (intel_dp->is_mst) {
> > > > >  			drm_dbg_kms(&dev_priv->drm,
> > > > >  				    "MST device may have disappeared %d vs %d\n",
> > > > > @@ -6152,15 +6169,8 @@ intel_dp_detect(struct drm_connector *connector,
> > > > >  		goto out;
> > > > >  	}
> > > > >  
> > > > > -	if (intel_dp->reset_link_params) {
> > > > > -		/* Initial max link lane count */
> > > > > -		intel_dp->max_link_lane_count = intel_dp_max_common_lane_count(intel_dp);
> > > > > -
> > > > > -		/* Initial max link rate */
> > > > > -		intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
> > > > > -
> > > > > -		intel_dp->reset_link_params = false;
> > > > > -	}
> > > > > +	if (intel_dp->reset_link_params)
> > > > > +		intel_dp_reset_link_params(intel_dp);
> > > > >  
> > > > >  	intel_dp_print_rates(intel_dp);
> > > > >  
> > > > > -- 
> > > > > 2.19.1
> > > > 
> > > > -- 
> > > > Ville Syrjälä
> > > > Intel
> > 
> > -- 
> > Ville Syrjälä
> > Intel

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx