On Thu, Apr 06, 2017 at 05:31:07PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 06, 2017 at 04:44:18PM +0300, Jani Nikula wrote:
> > From: Manasi Navare <manasi.d.navare@xxxxxxxxx>
> >
> > Currently intel_dp_check_link_status() tries to retrain the link if
> > Clock recovery or Channel EQ for any of the lanes indicated by
> > intel_dp->lane_count is not set. However these values cached in intel_dp
> > structure can be stale if link training has failed for these values
> > during previous modeset. Or these values can get stale since we have
> > now re read the DPCD registers or it can be 0 in case of connected boot
> > case.
> >
> > This patch validates these values against the common_rates and max lane
> > count values.
> >
> > This is absolutely required incase the common_rates or max lane count
> > are now different due to link fallback.
> >
> > v2:
> > * Include the FIXME commnet inside the function (Ville Syrjala)
> > * Remove the redundant parenthesis (Ville Syrjala)
> >
> > v3 by Jani:
> > * rebase on the DP refactoring series
> > * rename intel_dp_link_params_is_valid to intel_dp_link_params_valid
> > * minor stylistic changes
> >
> > Cc: Ville Syrjala <ville.syrjala@xxxxxxxxxxxxxxx>
> > Cc: Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx>
> > Signed-off-by: Manasi Navare <manasi.d.navare@xxxxxxxxx>
> > Signed-off-by: Jani Nikula <jani.nikula@xxxxxxxxx>
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 30 +++++++++++++++++++++++++++---
> > 1 file changed, 27 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index 3c5c80da9ea3..6915d89a238c 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -322,6 +322,28 @@ static int intel_dp_common_len_rate_limit(struct intel_dp *intel_dp,
> > return 0;
> > }
> >
> > +static bool intel_dp_link_params_valid(struct intel_dp *intel_dp)
> > +{
> > + int index;
> > +
> > + /*
> > + * FIXME: we need to synchronize the current link parameters with
> > + * hardware readout. Currently fast link training doesn't work on
> > + * boot-up.
> > + */
> > + index = intel_dp_rate_index(intel_dp->common_rates,
> > + intel_dp->num_common_rates,
> > + intel_dp->link_rate);
> > + if (index < 0)
> > + return false;
>
> Hmm. Isn't common_rates[] still just the intersection of the source
> and sink rates? So it looks to me like this should actually just check
> for 'link_rate == 0 || link_rate > max_link_rate', or something similar.
>
Yes that is true. Passing common_rates worked earlier to see if the link
rate was within the bounds and still less than the lowered fallback link rate
becuase we were changing the common_rates.
But now with this new series, you are right that we cannot use common_rates array
because it is still the intersection of just sink and source rates and wont
take into account the lowered fallback rate unless we pass the length of common
rates array limited by the max link rate by calling intel_dp_common_len_rate_limit()
or we could just check that it is greater than 0 and less than the max_link_rate.
Does that sound right to you?
I will update this logic and send a new revision.
Regards
Manasi
> > +
> > + if (intel_dp->lane_count == 0 ||
> > + intel_dp->lane_count > intel_dp_max_lane_count(intel_dp))
> > + return false;
> > +
> > + return true;
> > +}
> > +
> > int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> > int link_rate, uint8_t lane_count)
> > {
> > @@ -4253,9 +4275,11 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
> > if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> > return;
> >
> > - /* FIXME: we need to synchronize this sort of stuff with hardware
> > - * readout. Currently fast link training doesn't work on boot-up. */
> > - if (!intel_dp->lane_count)
> > + /*
> > + * Validate the cached values of intel_dp->link_rate and
> > + * intel_dp->lane_count before attempting to retrain.
> > + */
> > + if (!intel_dp_link_params_valid(intel_dp))
> > return;
> >
> > /* Retrain if Channel EQ or CR not ok */
> > --
> > 2.1.4
>
> --
> Ville Syrjälä
> Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
