Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1538588

RE: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM.

From <Andrei.Pistirica@microchip.com>
Newsgroups linux.kernel
Subject RE: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM.
Date 2016-12-08 15:50 +0100
Message-ID <sM8bf-7j1-15@gated-at.bofh.it> (permalink)
References <sLMkq-1Oz-25@gated-at.bofh.it> <sLQem-4fD-11@gated-at.bofh.it> <sLRN7-5kc-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw



> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran@gmail.com]
> Sent: Wednesday, December 07, 2016 11:04 PM
> To: Andrei Pistirica - M16132
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; davem@davemloft.net;
> nicolas.ferre@atmel.com; harinikatakamlinux@gmail.com;
> harini.katakam@xilinx.com; punnaia@xilinx.com; michals@xilinx.com;
> anirudh@xilinx.com; boris.brezillon@free-electrons.com;
> alexandre.belloni@free-electrons.com; tbultel@pixelsurmer.com;
> rafalo@cadence.com
> Subject: Re: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in
> Cadence GEM.
> 
> 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 considered the following simple equation: increment value at nominal frequency (which is 10^9/nominal frequency nsecs) + the maximum drift value (nsecs) <= maximum increment value at nominal frequency (which is 8bit:0xffff).
If maximum drift is written as function of nominal frequency and maximum ppb, then the equation above yields that the maximum ppb is: (2^8 - 1) *nominal_frequency - 10^9. The equation is also simplified by the fact that the drift is written as ppm + 16bit_fractions and the increment value is written as nsec + 16bit_fractions.

Rafal said that this value is hardcoded: 0x64E6, while Harini said: 250000000.

I need to dig into this...

> 
> I am not sure what you meant, but it sounds like you are on the wrong track.
> Let me explain...

Thanks.

> 
> 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
> 
> 

Regards,
Andrei

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM. Andrei Pistirica <andrei.pistirica@microchip.com> - 2016-12-07 16:30 +0100
  [RFC PATCH net-next v3 2/2] macb: Enable 1588 support in SAMA5Dx platforms. Andrei Pistirica <andrei.pistirica@microchip.com> - 2016-12-07 16:30 +0100
    Re: [RFC PATCH net-next v3 2/2] macb: Enable 1588 support in SAMA5Dx  platforms. Richard Cochran <richardcochran@gmail.com> - 2016-12-07 20:50 +0100
  Re: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence  GEM. Richard Cochran <richardcochran@gmail.com> - 2016-12-07 20:40 +0100
    Re: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence  GEM. Richard Cochran <richardcochran@gmail.com> - 2016-12-07 22:20 +0100
      RE: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence  GEM. <Andrei.Pistirica@microchip.com> - 2016-12-08 15:50 +0100
        Re: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM. Harini Katakam <harinikatakamlinux@gmail.com> - 2016-12-09 06:40 +0100
          Re: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence  GEM. Richard Cochran <richardcochran@gmail.com> - 2016-12-09 10:00 +0100
        RE: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence  GEM. Rafal Ozieblo <rafalo@cadence.com> - 2016-12-09 10:30 +0100
    Re: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence  GEM. Nicolas Ferre <nicolas.ferre@atmel.com> - 2016-12-08 11:10 +0100

csiph-web