From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com>
Cc: Marc Herbert <Marc.Herbert@intel.com>,
intel-gfx@lists.freedesktop.org, dhinakaran.pandiyan@intel.com
Subject: Re: [PATCH v3] drm/i915/dp: Give up link training clock recovery after 10 failed attempts
Date: Mon, 16 Jul 2018 16:39:13 -0700 [thread overview]
Message-ID: <20180716233913.GF2324@intel.com> (raw)
In-Reply-To: <20180716232747.GB19088@nc-new>
On Mon, Jul 16, 2018 at 04:27:47PM -0700, Nathan Ciobanu wrote:
> On Mon, Jul 16, 2018 at 03:30:49PM -0700, Rodrigo Vivi wrote:
> > On Mon, Jul 16, 2018 at 12:22:13PM -0700, Marc Herbert wrote:
> > >
> > > While the shortness of v3 is really nice, I think it's rather a good
> > > opportunity to make much clearer (as a separate, no functional change
> > > patch?) its existing terminating condition(s) and what the existing loop
> > > iterates on. I mean it's painful and risky enough to _combine multiple
> > > counters in the same loop_, so at least these different counters should be
> > > _invidually_ crystal-clear with enough comments. For instance let's pretend
> > > there are 4 possible voltage values and that each value is tried 4 times -
> > > then the last value will never be tried! Can this ever happen? If not then
> > > why not? Not even with a buggy sink? If it can happen then is it fine to
> > > give up before trying some values? Is it compliant with the spec? Etc.
> >
> > hm.. it seems that that code has room for improvements to make it more
> > clear and easier to map with the spec...
> > but yeap, separated patches.
> Do we like to add macros for the other counters? I can try to clarify this a bit.
>
> >
> > >
> > > This should incidentally help clarify why and how the current logic allows
> > > infinite loops.
> > >
> > > BTW "max_vswing_tries" looks like a boolean, correct? If correct then please
> > > remove this confusing "increment from false to true":
> > >
> > > - if (max_vswing_tries == 1)
> > > + if (max_vswing_tries)
> > >
> > > - max_vswing_tries++;
> > > + max_vwing_tries = true;
> >
> > if we change to boolean it is better to really change the type
> > and remove "_tries" from the name....
> Yup, will do!
please note I'm not telling that we "should do"... but only "if we do" ;)
>
> >
> > >
> > > Marc
> > >
> > >
> > > On 16/07/2018 11:14, Nathan Ciobanu wrote:
> > > > Signed-off-by: Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/intel_dp_link_training.c | 7 +++++--
> > > > include/drm/drm_dp_helper.h | 1 +
> > > > 2 files changed, 6 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > index 4da6e33c7fa1..4bfba65c431c 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > @@ -129,7 +129,7 @@ static bool intel_dp_link_max_vswing_reached(struct intel_dp *intel_dp)
> > > > intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> > > > {
> > > > uint8_t voltage;
> > > > - int voltage_tries, max_vswing_tries;
> > > > + int voltage_tries, max_vswing_tries, cr_tries;
> > > > uint8_t link_config[2];
> > > > uint8_t link_bw, rate_select;
> > > >
> > > > @@ -172,7 +172,7 @@ static bool intel_dp_link_max_vswing_reached(struct intel_dp *intel_dp)
> > > >
> > > > voltage_tries = 1;
> > > > max_vswing_tries = 0;
> > > > - for (;;) {
> > > > + for (cr_tries = 0; cr_tries < DP_DP14_MAX_CR_TRIES; ++cr_tries) {
> > > > uint8_t link_status[DP_LINK_STATUS_SIZE];
> > > >
> > > > drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
> > > > @@ -216,6 +216,9 @@ static bool intel_dp_link_max_vswing_reached(struct intel_dp *intel_dp)
> > > > ++max_vswing_tries;
> > > >
> > > > }
> > > > + DRM_ERROR("Failed clock recovery %d times, giving up!\n",
> > > > + DP_DP14_MAX_CR_TRIES);
> > > > + return false;
> > > > }
> > > >
> >
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-07-16 23:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-16 18:14 [PATCH v3] drm/i915/dp: Give up link training clock recovery after 10 failed attempts Nathan Ciobanu
2018-07-16 19:22 ` Marc Herbert
2018-07-16 22:30 ` Rodrigo Vivi
2018-07-16 23:27 ` Nathan Ciobanu
2018-07-16 23:39 ` Rodrigo Vivi [this message]
2018-07-16 22:34 ` Rodrigo Vivi
2018-07-16 23:23 ` Nathan Ciobanu
2018-07-16 23:40 ` Rodrigo Vivi
2018-07-16 23:51 ` Marc Herbert
2018-07-17 22:21 ` Dhinakaran Pandiyan
2018-07-18 1:05 ` Nathan Ciobanu
2018-07-18 3:00 ` Dhinakaran Pandiyan
2018-07-19 17:01 ` Rodrigo Vivi
2018-07-19 18:42 ` Nathan Ciobanu
2018-07-17 8:01 ` ✗ Fi.CI.BAT: failure for drm/i915/dp: Give up link training clock recovery after 10 failed attempts (rev3) Patchwork
2018-07-17 9:24 ` ✓ Fi.CI.IGT: success " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180716233913.GF2324@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=Marc.Herbert@intel.com \
--cc=dhinakaran.pandiyan@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=nathan.d.ciobanu@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.