[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161109131146.GA6491@localhost.localdomain>
Date: Wed, 9 Nov 2016 14:11:46 +0100
From: Richard Cochran <richardcochran@...il.com>
To: "Keller, Jacob E" <jacob.e.keller@...el.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"Manfred.Rudigier@...cron.at" <Manfred.Rudigier@...cron.at>,
"ulrik.debie-os@...ig.org" <ulrik.debie-os@...ig.org>,
"stefan.sorensen@...ctralink.com" <stefan.sorensen@...ctralink.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
"john.stultz@...aro.org" <john.stultz@...aro.org>,
"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>
Subject: Re: [PATCH net-next 2/3] ptp: igb: Use the high resolution frequency
method.
On Tue, Nov 08, 2016 at 10:02:22PM +0000, Keller, Jacob E wrote:
> On Tue, 2016-11-08 at 22:49 +0100, Richard Cochran wrote:
> > - rate = ppb;
> > - rate <<= 26;
> > - rate = div_u64(rate, 1953125);
> > + rate = scaled_ppm;
> > + rate <<= 13;
> > + rate = div_u64(rate, 15625);
>
> I'm curious how you generate the new math here, since this can be
> tricky, and I could use more examples in order to port to some of the
> other drivers implementations. I'm not quit sure how to handle the
> value when the lower 16 bits are fractional.
TL;DR version:
In ptp_clock.c we convert scaled_ppm to ppb like this.
ppb = scaled_ppm * 10^3 * 2^-16
If you already have a working driver that does
regval = ppb * SOMEMATH;
then just substitute
regval = (scaled_ppm * 10^3 * 2^-16) * SOMEMATH;
= (scaled_ppm * 5^3 * 2^-13) * SOMEMATH;
and simplify by combining the 5^3 and 2^-13 constants into SOMEMATH.
Longer explanation:
You have to consider how the frequency adjustment HW works, case by
case. Both the i210 and the phyter have an adjustment register that
holds units of 2^-32 nanoseconds per 8 nanosecond clock period, and so
the rate from adjustment value 1 is (2^-32 / 8).
Then with the old interface, the conversion from "adjustment unit" to
ppb was (2^-32 / 8 * 10^9) or (2^-26 * 5^9). The conversion the other
way needs the inverse, and so the code did (ppb << 26) / 5^9.
With the new interface, the conversion from "adjustment unit" to
scaled_ppm is (2^-32 / 8 * 10^6 * 2^16) or (2^-13 * 5^6). The code
converts the other direction using the inverse, (s_ppm << 13) / 5^6.
HTH,
Richard
Powered by blists - more mailing lists