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

[Richard Cochran <richardcochran@gmail.com>]

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