From: Thierry Reding <thierry.reding@gmail.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/dp: Do not busy-loop during link training
Date: Mon, 11 Jan 2016 09:36:04 +0100 [thread overview]
Message-ID: <20160111083604.GA11159@ulmo> (raw)
In-Reply-To: <20151214163028.GS4437@intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 1788 bytes --]
On Mon, Dec 14, 2015 at 06:30:28PM +0200, Ville Syrjälä wrote:
> On Mon, Dec 14, 2015 at 04:23:41PM +0100, Thierry Reding wrote:
> > On Mon, Dec 14, 2015 at 04:48:09PM +0200, Ville Syrjälä wrote:
> > > On Mon, Dec 14, 2015 at 02:21:56PM +0100, Thierry Reding wrote:
> > > > From: Thierry Reding <treding@nvidia.com>
> > > >
> > > > Use microsecond sleeps for the clock recovery and channel equalization
> > > > delays during link training. The duration of these delays can be from
> > > > 100 us up to 16 ms. It is rude to busy-loop for that amount of time.
> > >
> > > Do you have some numbers on how this affects a typical link training
> > > cycle?
> >
> > Not really. Sinks aren't required to provide a value here, in which case
> > the specification says that a default of 100 us and 400 us should be
> > used for clock recovery and channel equalization, respectively. If the
> > sink provides an AUX_RD_INTERVAL value, it is used for both CR and CE
> > (and is in units of 4 ms). Best case a typical link training cycle would
> > therefore take something like 0.5 ms and worst case, since the number of
> > retries should be limited to 5, it'd be around 5 * 16 ms = 80 ms. That's
> > not counting the actual AUX transactions, though they should be pretty
> > fast.
> >
> > Since this patch uses usleep_range(min, min * 2) the worst case now
> > becomes ~ 160 ms.
>
> Would be nice to have some *actual* numbers in the commit message,
> otherwise it's all just guesswork.
I only have a limited range of test equipment. In the primary test-case,
which is an eDP panel, the difference was ~4.5 ms for udelay()/mdelay()
and ~5 ms for the usleep_range() case. I'll see if I can get one more
test setup running for better comparison.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2016-01-11 8:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-14 13:21 [PATCH] drm/dp: Do not busy-loop during link training Thierry Reding
2015-12-14 14:48 ` Ville Syrjälä
2015-12-14 15:23 ` Thierry Reding
2015-12-14 16:30 ` Ville Syrjälä
2016-01-11 8:36 ` Thierry Reding [this message]
2016-01-11 19:18 ` Ville Syrjälä
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=20160111083604.GA11159@ulmo \
--to=thierry.reding@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=ville.syrjala@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.