* [PATCH] drm/i915/dp: Validate cached link rate and lane count before retraining
@ 2017-03-23 23:11 Manasi Navare
2017-03-24 10:56 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-03-27 13:40 ` [PATCH] " Ville Syrjälä
0 siblings, 2 replies; 9+ messages in thread
From: Manasi Navare @ 2017-03-23 23:11 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.
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 | 24 +++++++++++++++++++++---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fd96a6c..51fa6b5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -295,6 +295,23 @@ 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;
+
+ 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 +4241,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] 9+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915/dp: Validate cached link rate and lane count before retraining
2017-03-23 23:11 [PATCH] drm/i915/dp: Validate cached link rate and lane count before retraining Manasi Navare
@ 2017-03-24 10:56 ` Patchwork
2017-03-27 13:40 ` [PATCH] " Ville Syrjälä
1 sibling, 0 replies; 9+ messages in thread
From: Patchwork @ 2017-03-24 10:56 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
URL : https://patchwork.freedesktop.org/series/21797/
State : success
== Summary ==
Series 21797v1 drm/i915/dp: Validate cached link rate and lane count before retraining
https://patchwork.freedesktop.org/api/1.0/series/21797/revisions/1/mbox/
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass -> INCOMPLETE (fi-bsw-n3050) fdo#100113
fdo#100113 https://bugs.freedesktop.org/show_bug.cgi?id=100113
fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time: 467s
fi-bdw-gvtdvm total:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time: 454s
fi-bsw-n3050 total:237 pass:201 dwarn:0 dfail:0 fail:0 skip:35 time: 0s
fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time: 545s
fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time: 562s
fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 time: 508s
fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 time: 503s
fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 433s
fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 437s
fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time: 440s
fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 511s
fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 496s
fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 476s
fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 486s
fi-skl-6700hq total:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time: 601s
fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time: 490s
fi-skl-6770hq total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 526s
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: 549s
fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time: 416s
fd27e1e4c9b5dc11966b4953432bd6e0510da308 drm-tip: 2017y-03m-24d-08h-39m-20s UTC integration manifest
44ec18c 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_4286/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] drm/i915/dp: Validate cached link rate and lane count before retraining
2017-03-23 23:11 [PATCH] drm/i915/dp: Validate cached link rate and lane count before retraining Manasi Navare
2017-03-24 10:56 ` ✓ Fi.CI.BAT: success for " Patchwork
@ 2017-03-27 13:40 ` Ville Syrjälä
2017-03-27 15:26 ` Jani Nikula
1 sibling, 1 reply; 9+ messages in thread
From: Ville Syrjälä @ 2017-03-27 13:40 UTC (permalink / raw)
To: Manasi Navare; +Cc: intel-gfx
On Thu, Mar 23, 2017 at 04:11:32PM -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.
>
> 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 | 24 +++++++++++++++++++++---
> 1 file changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index fd96a6c..51fa6b5 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -295,6 +295,23 @@ 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;
> +
> + link_rate_index = intel_dp_link_rate_index(intel_dp,
> + common_rates,
> + intel_dp->link_rate);
Hmm. I thought we started to store the common rates somewhere more
permanent, or did I imagine that?
> + if (link_rate_index < 0)
> + return false;
> + if (!intel_dp->lane_count ||
> + (intel_dp->lane_count > intel_dp_max_lane_count(intel_dp)))
Needless parens.
> + 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 +4241,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. */
You shouldn't remove the FIXME. It's still totally valid.
> - 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
--
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] 9+ messages in thread
* Re: [PATCH] drm/i915/dp: Validate cached link rate and lane count before retraining
2017-03-27 13:40 ` [PATCH] " Ville Syrjälä
@ 2017-03-27 15:26 ` Jani Nikula
2017-03-27 16:53 ` Manasi Navare
0 siblings, 1 reply; 9+ messages in thread
From: Jani Nikula @ 2017-03-27 15:26 UTC (permalink / raw)
To: Ville Syrjälä, Manasi Navare; +Cc: intel-gfx
On Mon, 27 Mar 2017, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Thu, Mar 23, 2017 at 04:11:32PM -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.
>>
>> 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 | 24 +++++++++++++++++++++---
>> 1 file changed, 21 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>> index fd96a6c..51fa6b5 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -295,6 +295,23 @@ 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;
>> +
>> + link_rate_index = intel_dp_link_rate_index(intel_dp,
>> + common_rates,
>> + intel_dp->link_rate);
>
> Hmm. I thought we started to store the common rates somewhere more
> permanent, or did I imagine that?
That series got stalled waiting for Manasi's stuff to land... which
means it's now conflicting and pending rebase, and still waiting. :(
J.
>
>> + if (link_rate_index < 0)
>> + return false;
>> + if (!intel_dp->lane_count ||
>> + (intel_dp->lane_count > intel_dp_max_lane_count(intel_dp)))
>
> Needless parens.
>
>> + 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 +4241,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. */
>
> You shouldn't remove the FIXME. It's still totally valid.
>
>> - 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] 9+ messages in thread
* Re: [PATCH] drm/i915/dp: Validate cached link rate and lane count before retraining
2017-03-27 15:26 ` Jani Nikula
@ 2017-03-27 16:53 ` Manasi Navare
2017-03-27 17:21 ` Ville Syrjälä
2017-03-28 7:34 ` Jani Nikula
0 siblings, 2 replies; 9+ messages in thread
From: Manasi Navare @ 2017-03-27 16:53 UTC (permalink / raw)
To: Jani Nikula; +Cc: intel-gfx
On Mon, Mar 27, 2017 at 06:26:06PM +0300, Jani Nikula wrote:
> On Mon, 27 Mar 2017, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > On Thu, Mar 23, 2017 at 04:11:32PM -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.
> >>
> >> 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 | 24 +++++++++++++++++++++---
> >> 1 file changed, 21 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> >> index fd96a6c..51fa6b5 100644
> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> @@ -295,6 +295,23 @@ 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;
> >> +
> >> + link_rate_index = intel_dp_link_rate_index(intel_dp,
> >> + common_rates,
> >> + intel_dp->link_rate);
> >
> > Hmm. I thought we started to store the common rates somewhere more
> > permanent, or did I imagine that?
>
> That series got stalled waiting for Manasi's stuff to land... which
> means it's now conflicting and pending rebase, and still waiting. :(
>
> J.
>
Hmm, yes but if you want I can work on rebasing it after these two patches
land. That series is really required.
>
> >
> >> + if (link_rate_index < 0)
> >> + return false;
> >> + if (!intel_dp->lane_count ||
> >> + (intel_dp->lane_count > intel_dp_max_lane_count(intel_dp)))
> >
> > Needless parens.
> >
Ok, will remove that.
> >> + 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 +4241,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. */
> >
> > You shouldn't remove the FIXME. It's still totally valid.
> >
But that check is now incorporated in validating the params.
So why is separate check required?
Or are you just saying leave the FIXME comment?
Manasi
> >> - 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] 9+ messages in thread
* Re: [PATCH] drm/i915/dp: Validate cached link rate and lane count before retraining
2017-03-27 16:53 ` Manasi Navare
@ 2017-03-27 17:21 ` Ville Syrjälä
2017-03-27 18:44 ` Manasi Navare
2017-03-28 7:34 ` Jani Nikula
1 sibling, 1 reply; 9+ messages in thread
From: Ville Syrjälä @ 2017-03-27 17:21 UTC (permalink / raw)
To: Manasi Navare; +Cc: intel-gfx
On Mon, Mar 27, 2017 at 09:53:36AM -0700, Manasi Navare wrote:
> On Mon, Mar 27, 2017 at 06:26:06PM +0300, Jani Nikula wrote:
> > On Mon, 27 Mar 2017, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > On Thu, Mar 23, 2017 at 04:11:32PM -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.
> > >>
> > >> 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 | 24 +++++++++++++++++++++---
> > >> 1 file changed, 21 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > >> index fd96a6c..51fa6b5 100644
> > >> --- a/drivers/gpu/drm/i915/intel_dp.c
> > >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> > >> @@ -295,6 +295,23 @@ 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;
> > >> +
> > >> + link_rate_index = intel_dp_link_rate_index(intel_dp,
> > >> + common_rates,
> > >> + intel_dp->link_rate);
> > >
> > > Hmm. I thought we started to store the common rates somewhere more
> > > permanent, or did I imagine that?
> >
> > That series got stalled waiting for Manasi's stuff to land... which
> > means it's now conflicting and pending rebase, and still waiting. :(
> >
> > J.
> >
>
> Hmm, yes but if you want I can work on rebasing it after these two patches
> land. That series is really required.
>
>
> >
> > >
> > >> + if (link_rate_index < 0)
> > >> + return false;
> > >> + if (!intel_dp->lane_count ||
> > >> + (intel_dp->lane_count > intel_dp_max_lane_count(intel_dp)))
> > >
> > > Needless parens.
> > >
>
> Ok, will remove that.
>
>
> > >> + 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 +4241,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. */
> > >
> > > You shouldn't remove the FIXME. It's still totally valid.
> > >
>
> But that check is now incorporated in validating the params.
> So why is separate check required?
> Or are you just saying leave the FIXME comment?
Yes, leave the comment. Or better yet, move into
intel_dp_link_params_is_valid() and maybe reword a bit to something
like:
"FIXME: we need to synchronize the current link parameters with hardware
readout ..."
to make it it clear that it's actually referring to the current link
params and not something else.
>
> Manasi
>
>
> > >> - 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] 9+ messages in thread
* Re: [PATCH] drm/i915/dp: Validate cached link rate and lane count before retraining
2017-03-27 17:21 ` Ville Syrjälä
@ 2017-03-27 18:44 ` Manasi Navare
0 siblings, 0 replies; 9+ messages in thread
From: Manasi Navare @ 2017-03-27 18:44 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
On Mon, Mar 27, 2017 at 08:21:21PM +0300, Ville Syrjälä wrote:
> On Mon, Mar 27, 2017 at 09:53:36AM -0700, Manasi Navare wrote:
> > On Mon, Mar 27, 2017 at 06:26:06PM +0300, Jani Nikula wrote:
> > > On Mon, 27 Mar 2017, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > On Thu, Mar 23, 2017 at 04:11:32PM -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.
> > > >>
> > > >> 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 | 24 +++++++++++++++++++++---
> > > >> 1 file changed, 21 insertions(+), 3 deletions(-)
> > > >>
> > > >> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > > >> index fd96a6c..51fa6b5 100644
> > > >> --- a/drivers/gpu/drm/i915/intel_dp.c
> > > >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > >> @@ -295,6 +295,23 @@ 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;
> > > >> +
> > > >> + link_rate_index = intel_dp_link_rate_index(intel_dp,
> > > >> + common_rates,
> > > >> + intel_dp->link_rate);
> > > >
> > > > Hmm. I thought we started to store the common rates somewhere more
> > > > permanent, or did I imagine that?
> > >
> > > That series got stalled waiting for Manasi's stuff to land... which
> > > means it's now conflicting and pending rebase, and still waiting. :(
> > >
> > > J.
> > >
> >
> > Hmm, yes but if you want I can work on rebasing it after these two patches
> > land. That series is really required.
> >
> >
> > >
> > > >
> > > >> + if (link_rate_index < 0)
> > > >> + return false;
> > > >> + if (!intel_dp->lane_count ||
> > > >> + (intel_dp->lane_count > intel_dp_max_lane_count(intel_dp)))
> > > >
> > > > Needless parens.
> > > >
> >
> > Ok, will remove that.
> >
> >
> > > >> + 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 +4241,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. */
> > > >
> > > > You shouldn't remove the FIXME. It's still totally valid.
> > > >
> >
> > But that check is now incorporated in validating the params.
> > So why is separate check required?
> > Or are you just saying leave the FIXME comment?
>
> Yes, leave the comment. Or better yet, move into
> intel_dp_link_params_is_valid() and maybe reword a bit to something
> like:
>
> "FIXME: we need to synchronize the current link parameters with hardware
> readout ..."
>
> to make it it clear that it's actually referring to the current link
> params and not something else.
>
>
Ok, I will move the comment into the function.
And submit a new revision. Everything else looks good?
Regards
Manasi
> >
> > Manasi
> >
> >
> > > >> - 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] 9+ messages in thread
* Re: [PATCH] drm/i915/dp: Validate cached link rate and lane count before retraining
2017-03-27 16:53 ` Manasi Navare
2017-03-27 17:21 ` Ville Syrjälä
@ 2017-03-28 7:34 ` Jani Nikula
2017-03-28 15:46 ` Manasi Navare
1 sibling, 1 reply; 9+ messages in thread
From: Jani Nikula @ 2017-03-28 7:34 UTC (permalink / raw)
To: Manasi Navare; +Cc: intel-gfx
On Mon, 27 Mar 2017, Manasi Navare <manasi.d.navare@intel.com> wrote:
> Hmm, yes but if you want I can work on rebasing it after these two patches
> land. That series is really required.
I can do the rebasing, I'll just need the review from you. ;)
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] 9+ messages in thread
* Re: [PATCH] drm/i915/dp: Validate cached link rate and lane count before retraining
2017-03-28 7:34 ` Jani Nikula
@ 2017-03-28 15:46 ` Manasi Navare
0 siblings, 0 replies; 9+ messages in thread
From: Manasi Navare @ 2017-03-28 15:46 UTC (permalink / raw)
To: Jani Nikula; +Cc: intel-gfx
On Tue, Mar 28, 2017 at 10:34:42AM +0300, Jani Nikula wrote:
> On Mon, 27 Mar 2017, Manasi Navare <manasi.d.navare@intel.com> wrote:
> > Hmm, yes but if you want I can work on rebasing it after these two patches
> > land. That series is really required.
>
> I can do the rebasing, I'll just need the review from you. ;)
>
Yes absolutely, i will review it today. I had looked at this and tested it
earlier as well.
So I submitted v2 for Validate link params patch yesterday, that would have to be rebased?
And how about the Implement link rate fallback patch? Does that need to be rebased?
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] 9+ messages in thread
end of thread, other threads:[~2017-03-28 15:42 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-23 23:11 [PATCH] drm/i915/dp: Validate cached link rate and lane count before retraining Manasi Navare
2017-03-24 10:56 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-03-27 13:40 ` [PATCH] " Ville Syrjälä
2017-03-27 15:26 ` Jani Nikula
2017-03-27 16:53 ` Manasi Navare
2017-03-27 17:21 ` Ville Syrjälä
2017-03-27 18:44 ` Manasi Navare
2017-03-28 7:34 ` Jani Nikula
2017-03-28 15:46 ` 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.