Re: [PATCH] drm/i915/edp: Do not do link training fallback or prune modes on EDP

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

 



On Thu, Oct 12, 2017 at 08:37:10PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 11, 2017 at 04:19:45PM -0700, Manasi Navare wrote:
> > In case of eDP because the panel has a fixed mode, the link rate
> > and lane count at which it is trained corresponds to the link BW
> > required to support the native resolution of the panel. In case of
> > panles with lower resolutions where fewer lanes are hooked up internally,
> > that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
> > So it is pointless to fallback to lower link rate/lane count in case
> > of link training failure on eDP connector since the lower link BW
> > will not support the native resolution of the panel and we cannot
> > prune the preferred mode on the eDP connector.
> > 
> > In case of Link training failure on the eDP panel, something is wrong
> > in the HW internally and hence driver errors out with a loud
> > and clear DRM_ERROR message.
> > 
> > Cc: Clinton Taylor <clinton.a.taylor@xxxxxxxxx>
> > Cc: Jim Bride <jim.bride@xxxxxxxxxxxxxxx>
> > Cc: Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx>
> > Cc: Ville Syrjala <ville.syrjala@xxxxxxxxxxxxxxx>
> > Cc: Dave Airlie <airlied@xxxxxxxxxx>
> > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx>
> > Signed-off-by: Manasi Navare <manasi.d.navare@xxxxxxxxx>
> > ---
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 25 ++++++++++++++++---------
> >  1 file changed, 16 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index 05907fa..bcccef1 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -328,14 +328,21 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
> >  	return;
> >  
> >   failure_handling:
> > -	DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
> > -		      intel_connector->base.base.id,
> > -		      intel_connector->base.name,
> > -		      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);
> > +	/* Dont fallback and prune modes if its eDP */
> > +	if (!intel_dp_is_edp(intel_dp)) {
> > +		DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
> > +			      intel_connector->base.base.id,
> > +			      intel_connector->base.name,
> > +			      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);
> > +	} else
> 
> {} missing around the else. The conventio is to put {} around every
> branch if at least one branch needs them.
> 
> > +		DRM_ERROR("eDP [CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
>                            ^^^
> That's redundant since the connector name will alrady say "eDP-<something>"
> 
> Apart from that this seems better than blindly pruning the panel's
> native mode. If we ever hit this on real hardware we may have to think
> about your other idea of trying to reduce the link params in a way
> that doesn't result the loss of the native mode.
>

Yes I agree. I started coding that logic at first but it becomes a little
bit of a stretch considering the fact that we should never run into that
situation.
So I agree that unless we actually see this on a real HW we should just avoid lowering
link rate/lane count.
 
> With the redundant stuff in the error message dropped and {} added this is
> Reviewed-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
>

Thanks for the review comments. Yes i will fix the debug message and add the necessary {}.

Manasi
 
> > +			  intel_connector->base.base.id,
> > +			  intel_connector->base.name,
> > +			  intel_dp->link_rate, intel_dp->lane_count);
> >  	return;
> >  }
> > -- 
> > 2.1.4
> 
> -- 
> Ville Syrjälä
> Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux