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... > 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. Thanks, Richard
