Re: [PATCH 0/3] Patch series for a PTP Grandmaster use case using stmmac/gmac3 ptp clock

[Olivier Dautricourt <olivier.dautricourt@orolia.com>]

The 05/14/2020 06:53, Richard Cochran wrote:
> On Thu, May 14, 2020 at 12:28:05PM +0200, Olivier Dautricourt wrote:
> > This patch series covers a use case where an embedded system is
> > disciplining an internal clock to a GNSS signal, which provides a
> > stable frequency, and wants to act as a PTP Grandmaster by disciplining
> > a ptp clock to this internal clock.
> 
> Have you seen the new GM patch series on the linuxptp-devel mailing
> list?  You may find it interesting...
  
  I have not, but i'll look deeper in the way this use case is handled
  in this series..

> 
> > In our setup a 10Mhz oscillator is frequency adjusted so that a derived
> > pps from that oscillator is in phase with the pps generated by
> > a gnss receiver.
> >
> > An other derived clock from the same disciplined oscillator is used as
> > ptp_clock for the ethernet mac.
> >
> > The internal pps of the system is forwarded to one of the auxiliary inputs
> > of the MAC.
> >
> > Initially the mac time registers are considered random.
> > We want the mac nanosecond field to be 0 on the auxiliary pps input edge.
> >
> >
> > PATCH 1/3:
> >       The stmmac gmac3 version used in the setup is patched to retrieve a
> >       timestamp at the rising edge of the aux input and to forward
> >       it to userspace.
> >
> > * What matters here is that we get the subsecond offset between the aux
> > edge and the edge of the PHC's pps. *
> >
> >
> > PATCH 2,3/3:
> >
> >       We want the ptp clock to be in time with our aux pps input.
> >       Since the ptp clock is derived from the system oscillator, we
> >       don't want to do frequency adjustements.
> >
> >       The stmmac driver is patched to allow to set the coarse correction
> >       mode which avoid to adjust the frequency of the mac continuously
> >       (the default behavior), but instead, have just one
> >       time adjustment.
> 
> You can use the new ts2phc program (in the linuxptp-devel patch
> series, soon to be merged) by configuring it to use the nullf servo.

  My issue is that the default behavior of the stmmac driver is to
  set the mac into fine mode which implies to continuously do frequency
  adjustment, So if i'm not mistaken using the nullf servo will not address
  that issue even if we are not doing explicit clock_adjtime syscalls.
  
  Patches 2/3 and 3/3 are reponsible for preventing this.
> 
> Thanks,
> Richard
> 
> ATTENTION: This email came from an external source.
> Do not open attachments or click on links from unknown senders or unexpected emails.

Regards,

-- 
Olivier Dautricourt