[Intel-gfx] [PATCH v2] drm/i915/dp: Validate cached link rate and lane count before retraining

[Manasi Navare]

On Wed, Mar 29, 2017 at 03:11:46PM +0300, Jani Nikula wrote:
> On Wed, 29 Mar 2017, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> > On Wed, Mar 29, 2017 at 10:29:24AM +0300, Jani Nikula wrote:
> >> On Tue, 28 Mar 2017, Manasi Navare <manasi.d.navare at intel.com> wrote:
> >> > Jani,
> >> >
> >> > Should I just hold on to this until your patch series
> >> > gets merged so I can rebase this on top of it?
> >> 
> >> I think I'd prefer that, especially so because I'm not sure that this
> >> patch does the right thing. Yes, this checks that the values are within
> >> bounds, but that they are within bounds doesn't make them any more valid
> >> for the current link if they are indeed stale!
> >
> > Can they be stale and still be within the bounds somehow?
> 
> Maybe not. Maybe I just don't follow. Perhaps the commit message
> deserves a better description of the cases where we hit the case.
>

So the idea here is to avoid using higher values of link rate/lane count
which are stale now due to an intermediate step of link rate fallback.
That is why the values cached in intel_dp structure will not be
within the bounds of common rates array and hence are termed as stale now.

Is there any other way for validating the values cached in intel_dp structure?
Since we dont zero them out on link failure, the driver can still mistaken them
as valid which is what I am trying to avoid here through this patch.

 
> >> >> +static bool intel_dp_link_params_is_valid(struct intel_dp *intel_dp)
> 
> Side note, it bugs me that the function name has a grammatical error.
> 
>

Change it to intel_dp_link_params_are_valid()?

Regards
Manasi

 
> BR,
> Jani.
> 
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center