* [PATCH v2] drm/i915/dp: Validate cached link rate and lane count before retraining
@ 2017-03-27 21:44 Manasi Navare
2017-03-27 22:16 ` ✓ Fi.CI.BAT: success for drm/i915/dp: Validate cached link rate and lane count before retraining (rev2) Patchwork
2017-03-28 15:55 ` [PATCH v2] drm/i915/dp: Validate cached link rate and lane count before retraining Manasi Navare
0 siblings, 2 replies; 7+ messages in thread
From: Manasi Navare @ 2017-03-27 21:44 UTC (permalink / raw)
To: intel-gfx
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)
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
---
drivers/gpu/drm/i915/intel_dp.c | 28 +++++++++++++++++++++++++---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fd96a6c..d0ab307 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -295,6 +295,27 @@ static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
return -1;
}
+static bool intel_dp_link_params_is_valid(struct intel_dp *intel_dp)
+{
+ int common_rates[DP_MAX_SUPPORTED_RATES];
+ int link_rate_index;
+
+ /* FIXME: we need to synchronize the current link parameters with
+ * hardware readout. Currently fast link training doesn't work
+ * on boot-up.
+ */
+ link_rate_index = intel_dp_link_rate_index(intel_dp,
+ common_rates,
+ intel_dp->link_rate);
+ if (link_rate_index < 0)
+ return false;
+ if (!intel_dp->lane_count ||
+ 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)
{
@@ -4224,9 +4245,10 @@ 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_is_valid(intel_dp))
return;
/* Retrain if Channel EQ or CR not ok */
--
2.1.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 7+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915/dp: Validate cached link rate and lane count before retraining (rev2)
2017-03-27 21:44 [PATCH v2] drm/i915/dp: Validate cached link rate and lane count before retraining Manasi Navare
@ 2017-03-27 22:16 ` Patchwork
2017-03-28 15:55 ` [PATCH v2] drm/i915/dp: Validate cached link rate and lane count before retraining Manasi Navare
1 sibling, 0 replies; 7+ messages in thread
From: Patchwork @ 2017-03-27 22:16 UTC (permalink / raw)
To: Navare, Manasi D; +Cc: intel-gfx
== Series Details ==
Series: drm/i915/dp: Validate cached link rate and lane count before retraining (rev2)
URL : https://patchwork.freedesktop.org/series/21797/
State : success
== Summary ==
Series 21797v2 drm/i915/dp: Validate cached link rate and lane count before retraining
https://patchwork.freedesktop.org/api/1.0/series/21797/revisions/2/mbox/
fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time: 458s
fi-bdw-gvtdvm total:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time: 453s
fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 time: 593s
fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time: 532s
fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time: 586s
fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 time: 509s
fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 time: 500s
fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 435s
fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 435s
fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time: 441s
fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 517s
fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 501s
fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 487s
fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 592s
fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 480s
fi-skl-6700hq total:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time: 595s
fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time: 497s
fi-skl-6770hq total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 522s
fi-skl-gvtdvm total:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time: 464s
fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time: 548s
fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time: 426s
c3ca5620be419c7e20c39d07f6cf7d1cb7c3bfc8 drm-tip: 2017y-03m-27d-20h-31m-03s UTC integration manifest
bbed7ea drm/i915/dp: Validate cached link rate and lane count before retraining
== Logs ==
For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4319/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] drm/i915/dp: Validate cached link rate and lane count before retraining
2017-03-27 21:44 [PATCH v2] drm/i915/dp: Validate cached link rate and lane count before retraining Manasi Navare
2017-03-27 22:16 ` ✓ Fi.CI.BAT: success for drm/i915/dp: Validate cached link rate and lane count before retraining (rev2) Patchwork
@ 2017-03-28 15:55 ` Manasi Navare
2017-03-29 7:29 ` Jani Nikula
1 sibling, 1 reply; 7+ messages in thread
From: Manasi Navare @ 2017-03-28 15:55 UTC (permalink / raw)
To: intel-gfx
Jani,
Should I just hold on to this until your patch series
gets merged so I can rebase this on top of it?
Regards
Manasi
On Mon, Mar 27, 2017 at 02:44:50PM -0700, Manasi Navare wrote:
> 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)
>
> Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> ---
> drivers/gpu/drm/i915/intel_dp.c | 28 +++++++++++++++++++++++++---
> 1 file changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index fd96a6c..d0ab307 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -295,6 +295,27 @@ static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
> return -1;
> }
>
> +static bool intel_dp_link_params_is_valid(struct intel_dp *intel_dp)
> +{
> + int common_rates[DP_MAX_SUPPORTED_RATES];
> + int link_rate_index;
> +
> + /* FIXME: we need to synchronize the current link parameters with
> + * hardware readout. Currently fast link training doesn't work
> + * on boot-up.
> + */
> + link_rate_index = intel_dp_link_rate_index(intel_dp,
> + common_rates,
> + intel_dp->link_rate);
> + if (link_rate_index < 0)
> + return false;
> + if (!intel_dp->lane_count ||
> + 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)
> {
> @@ -4224,9 +4245,10 @@ 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_is_valid(intel_dp))
> return;
>
> /* Retrain if Channel EQ or CR not ok */
> --
> 2.1.4
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] drm/i915/dp: Validate cached link rate and lane count before retraining
2017-03-28 15:55 ` [PATCH v2] drm/i915/dp: Validate cached link rate and lane count before retraining Manasi Navare
@ 2017-03-29 7:29 ` Jani Nikula
2017-03-29 11:46 ` Ville Syrjälä
0 siblings, 1 reply; 7+ messages in thread
From: Jani Nikula @ 2017-03-29 7:29 UTC (permalink / raw)
To: Manasi Navare, intel-gfx
On Tue, 28 Mar 2017, Manasi Navare <manasi.d.navare@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!
BR,
Jani.
>
> Regards
> Manasi
>
>
> On Mon, Mar 27, 2017 at 02:44:50PM -0700, Manasi Navare wrote:
>> 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)
>>
>> Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
>> Cc: Jani Nikula <jani.nikula@linux.intel.com>
>> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
>> ---
>> drivers/gpu/drm/i915/intel_dp.c | 28 +++++++++++++++++++++++++---
>> 1 file changed, 25 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>> index fd96a6c..d0ab307 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -295,6 +295,27 @@ static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
>> return -1;
>> }
>>
>> +static bool intel_dp_link_params_is_valid(struct intel_dp *intel_dp)
>> +{
>> + int common_rates[DP_MAX_SUPPORTED_RATES];
>> + int link_rate_index;
>> +
>> + /* FIXME: we need to synchronize the current link parameters with
>> + * hardware readout. Currently fast link training doesn't work
>> + * on boot-up.
>> + */
>> + link_rate_index = intel_dp_link_rate_index(intel_dp,
>> + common_rates,
>> + intel_dp->link_rate);
>> + if (link_rate_index < 0)
>> + return false;
>> + if (!intel_dp->lane_count ||
>> + 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)
>> {
>> @@ -4224,9 +4245,10 @@ 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_is_valid(intel_dp))
>> return;
>>
>> /* Retrain if Channel EQ or CR not ok */
>> --
>> 2.1.4
>>
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] drm/i915/dp: Validate cached link rate and lane count before retraining
2017-03-29 7:29 ` Jani Nikula
@ 2017-03-29 11:46 ` Ville Syrjälä
2017-03-29 12:11 ` Jani Nikula
0 siblings, 1 reply; 7+ messages in thread
From: Ville Syrjälä @ 2017-03-29 11:46 UTC (permalink / raw)
To: Jani Nikula; +Cc: intel-gfx
On Wed, Mar 29, 2017 at 10:29:24AM +0300, Jani Nikula wrote:
> On Tue, 28 Mar 2017, Manasi Navare <manasi.d.navare@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? That doesn't
make much sense to me. Althogh the way we shrink the set of valid params
doesn't make much sense to me either since we don't monotonically reduce
the link bw.
>
> BR,
> Jani.
>
>
> >
> > Regards
> > Manasi
> >
> >
> > On Mon, Mar 27, 2017 at 02:44:50PM -0700, Manasi Navare wrote:
> >> 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)
> >>
> >> Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> >> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> >> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> >> ---
> >> drivers/gpu/drm/i915/intel_dp.c | 28 +++++++++++++++++++++++++---
> >> 1 file changed, 25 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> >> index fd96a6c..d0ab307 100644
> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> @@ -295,6 +295,27 @@ static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
> >> return -1;
> >> }
> >>
> >> +static bool intel_dp_link_params_is_valid(struct intel_dp *intel_dp)
> >> +{
> >> + int common_rates[DP_MAX_SUPPORTED_RATES];
> >> + int link_rate_index;
> >> +
> >> + /* FIXME: we need to synchronize the current link parameters with
> >> + * hardware readout. Currently fast link training doesn't work
> >> + * on boot-up.
> >> + */
> >> + link_rate_index = intel_dp_link_rate_index(intel_dp,
> >> + common_rates,
> >> + intel_dp->link_rate);
> >> + if (link_rate_index < 0)
> >> + return false;
> >> + if (!intel_dp->lane_count ||
> >> + 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)
> >> {
> >> @@ -4224,9 +4245,10 @@ 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_is_valid(intel_dp))
> >> return;
> >>
> >> /* Retrain if Channel EQ or CR not ok */
> >> --
> >> 2.1.4
> >>
>
> --
> Jani Nikula, Intel Open Source Technology Center
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] drm/i915/dp: Validate cached link rate and lane count before retraining
2017-03-29 11:46 ` Ville Syrjälä
@ 2017-03-29 12:11 ` Jani Nikula
2017-03-29 17:41 ` Manasi Navare
0 siblings, 1 reply; 7+ messages in thread
From: Jani Nikula @ 2017-03-29 12:11 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
On Wed, 29 Mar 2017, Ville Syrjälä <ville.syrjala@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@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.
>> >> +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.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] drm/i915/dp: Validate cached link rate and lane count before retraining
2017-03-29 12:11 ` Jani Nikula
@ 2017-03-29 17:41 ` Manasi Navare
0 siblings, 0 replies; 7+ messages in thread
From: Manasi Navare @ 2017-03-29 17:41 UTC (permalink / raw)
To: Jani Nikula; +Cc: intel-gfx
On Wed, Mar 29, 2017 at 03:11:46PM +0300, Jani Nikula wrote:
> On Wed, 29 Mar 2017, Ville Syrjälä <ville.syrjala@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@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-03-29 17:37 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-27 21:44 [PATCH v2] drm/i915/dp: Validate cached link rate and lane count before retraining Manasi Navare
2017-03-27 22:16 ` ✓ Fi.CI.BAT: success for drm/i915/dp: Validate cached link rate and lane count before retraining (rev2) Patchwork
2017-03-28 15:55 ` [PATCH v2] drm/i915/dp: Validate cached link rate and lane count before retraining Manasi Navare
2017-03-29 7:29 ` Jani Nikula
2017-03-29 11:46 ` Ville Syrjälä
2017-03-29 12:11 ` Jani Nikula
2017-03-29 17:41 ` Manasi Navare
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.