Message ID | 1532471612-30001-1-git-send-email-nathan.d.ciobanu@linux.intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | drm/i915/dp: Improve clock recovery loop limit comment | expand |
Reviewed-by: Marc Herbert <marc.herbert@intel.com> Thx Nathan, I think this helps. I'm still curious how training normally converges much faster than the total number of possibilities but - unlike this latest clarification below - I expect the spec(s) to document that. On 24/07/2018 15:33, Nathan Ciobanu wrote: > Clarifies the clock recovery loop limit comment that 80 > max_cr_tries for pre-DP1.4 devices was chosen as a very > tolerant upper bound. > Assumptions made: > - DP1.4 syncs should be smarter so they won't need more > than 10 tries > - pre-DP1.4 syncs should be compliant enough to not need > that many tries (80) but we should tolerate any that may > trigger this corner case > > Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > Cc: Marc Herbert <marc.herbert@intel.com> > Suggested-by: Marc Herbert <marc.herbert@intel.com> > Signed-off-by: Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com> > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c > index 07e128c7443c..a9f40985a621 100644 > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c > @@ -172,10 +172,12 @@ static bool intel_dp_link_max_vswing_reached(struct intel_dp *intel_dp) > } > > /* > - * DP 1.4 spec clock recovery retries defined but > - * for devices pre-DP 1.4 we set the retry limit > - * to 4 (voltage levels) x 4 (preemphasis levels) x > - * x 5 (same voltage retries) = 80 (max iterations) > + * The DP 1.4 spec defines the max clock recovery retries value > + * as 10 but for pre-DP 1.4 devices we set a very tolerant > + * retry limit of 80 (4 voltage levels x 4 preemphasis levels x > + * x 5 identical voltage retries). Since the previous specs didn't > + * define a limit and created the possibility of an infinite loop > + * we want to prevent any sync from triggering that corner case. > */ > if (intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14) > max_cr_tries = 10; >
On Tue, Jul 24, 2018 at 05:17:53PM -0700, Marc Herbert wrote: > Reviewed-by: Marc Herbert <marc.herbert@intel.com> pushed, thanks. > > Thx Nathan, I think this helps. I'm still curious how training normally > converges much faster than the total number of possibilities but - unlike > this latest clarification below - I expect the spec(s) to document that. > > > On 24/07/2018 15:33, Nathan Ciobanu wrote: > > Clarifies the clock recovery loop limit comment that 80 > > max_cr_tries for pre-DP1.4 devices was chosen as a very > > tolerant upper bound. > > Assumptions made: > > - DP1.4 syncs should be smarter so they won't need more > > than 10 tries > > - pre-DP1.4 syncs should be compliant enough to not need > > that many tries (80) but we should tolerate any that may > > trigger this corner case > > > > Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > > Cc: Marc Herbert <marc.herbert@intel.com> > > Suggested-by: Marc Herbert <marc.herbert@intel.com> > > Signed-off-by: Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com> > > > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c > > index 07e128c7443c..a9f40985a621 100644 > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c > > @@ -172,10 +172,12 @@ static bool intel_dp_link_max_vswing_reached(struct intel_dp *intel_dp) > > } > > > > /* > > - * DP 1.4 spec clock recovery retries defined but > > - * for devices pre-DP 1.4 we set the retry limit > > - * to 4 (voltage levels) x 4 (preemphasis levels) x > > - * x 5 (same voltage retries) = 80 (max iterations) > > + * The DP 1.4 spec defines the max clock recovery retries value > > + * as 10 but for pre-DP 1.4 devices we set a very tolerant > > + * retry limit of 80 (4 voltage levels x 4 preemphasis levels x > > + * x 5 identical voltage retries). Since the previous specs didn't > > + * define a limit and created the possibility of an infinite loop > > + * we want to prevent any sync from triggering that corner case. > > */ > > if (intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14) > > max_cr_tries = 10; > > > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c index 07e128c7443c..a9f40985a621 100644 --- a/drivers/gpu/drm/i915/intel_dp_link_training.c +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c @@ -172,10 +172,12 @@ static bool intel_dp_link_max_vswing_reached(struct intel_dp *intel_dp) } /* - * DP 1.4 spec clock recovery retries defined but - * for devices pre-DP 1.4 we set the retry limit - * to 4 (voltage levels) x 4 (preemphasis levels) x - * x 5 (same voltage retries) = 80 (max iterations) + * The DP 1.4 spec defines the max clock recovery retries value + * as 10 but for pre-DP 1.4 devices we set a very tolerant + * retry limit of 80 (4 voltage levels x 4 preemphasis levels x + * x 5 identical voltage retries). Since the previous specs didn't + * define a limit and created the possibility of an infinite loop + * we want to prevent any sync from triggering that corner case. */ if (intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14) max_cr_tries = 10;
Clarifies the clock recovery loop limit comment that 80 max_cr_tries for pre-DP1.4 devices was chosen as a very tolerant upper bound. Assumptions made: - DP1.4 syncs should be smarter so they won't need more than 10 tries - pre-DP1.4 syncs should be compliant enough to not need that many tries (80) but we should tolerate any that may trigger this corner case Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Marc Herbert <marc.herbert@intel.com> Suggested-by: Marc Herbert <marc.herbert@intel.com> Signed-off-by: Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com>