From: richardcochran@gmail.com (Richard Cochran)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM.
Date: Wed, 7 Dec 2016 22:04:16 +0100 [thread overview]
Message-ID: <20161207210416.GA27622@netboy> (raw)
In-Reply-To: <20161207193908.GA13062@netboy>
On Wed, Dec 07, 2016 at 08:39:09PM +0100, Richard Cochran wrote:
> > +static s32 gem_ptp_max_adj(unsigned int f_nom)
> > +{
> > + u64 adj;
> > +
> > + /* The 48 bits of seconds for the GEM overflows every:
> > + * 2^48/(365.25 * 24 * 60 *60) =~ 8 925 512 years (~= 9 mil years),
> > + * thus the maximum adjust frequency must not overflow CNS register:
> > + *
> > + * addend = 10^9/nominal_freq
> > + * adj_max = +/- addend*ppb_max/10^9
> > + * max_ppb = (2^8-1)*nominal_freq-10^9
> > + */
> > + adj = f_nom;
> > + adj *= 0xffff;
> > + adj -= 1000000000ULL;
>
> What is this computation, and how does it relate to the comment?
I am not sure what you meant, but it sounds like you are on the wrong
track. Let me explain...
The max_adj has nothing at all to do with the width of the time
register. Rather, it should reflect the maximum possible change in
the tuning word.
For example, with a nominal 8 ns period, the tuning word is 0x80000.
Looking at running the clock more slowly, the slowest possible word is
0x00001, meaning a difference of 0x7FFFF. This implies an adjustment
of 0x7FFFF/0x80000 or 999998092 ppb. Running more quickly, we can
already have 0x100000, twice as fast, or just under 2 billion ppb.
You should consider the extreme cases to determine the most limited
(smallest) max_adj value:
Case 1 - high frequency
~~~~~~~~~~~~~~~~~~~~~~~
With a nominal 1 ns period, we have the nominal tuning word 0x10000.
The smallest is 0x1 for a difference of 0xFFFF. This corresponds to
an adjustment of 0xFFFF/0x10000 = .9999847412109375 or 999984741 ppb.
Case 2 - low frequency
~~~~~~~~~~~~~~~~~~~~~~
With a nominal 255 ns period, the nominal word is 0xFF0000, the
largest 0xFFFFFF, and the difference is 0xFFFF. This corresponds to
and adjustment of 0xFFFF/0xFF0000 = .0039215087890625 or 3921508 ppb.
Since 3921508 ppb is a huge adjustment, you can simply use that as a
safe maximum, ignoring the actual input clock.
Thanks,
Richard
next prev parent reply other threads:[~2016-12-07 21:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-07 18:21 [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM Andrei Pistirica
2016-12-07 18:21 ` [RFC PATCH net-next v3 2/2] macb: Enable 1588 support in SAMA5Dx platforms Andrei Pistirica
2016-12-07 19:43 ` Richard Cochran
2016-12-07 19:39 ` [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM Richard Cochran
2016-12-07 21:04 ` Richard Cochran [this message]
2016-12-08 14:41 ` Andrei.Pistirica at microchip.com
2016-12-09 5:37 ` Harini Katakam
2016-12-09 8:57 ` Richard Cochran
2016-12-09 9:20 ` Rafal Ozieblo
2016-12-12 10:22 ` Andrei.Pistirica at microchip.com
2016-12-12 10:34 ` Harini Katakam
2016-12-12 21:09 ` Richard Cochran
2016-12-08 9:59 ` Nicolas Ferre
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=20161207210416.GA27622@netboy \
--to=richardcochran@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).