Re: [PATCH net-next] ptp: add vclock timestamp conversion IOCTL

[Sebastien Laveze <sebastien.laveze@oss.nxp.com>]

On Mon, 2021-10-11 at 05:58 -0700, Richard Cochran wrote:
> Here is a simple example that has no solution, AFAICT.
> 
> - Imagine one physical and one virtual clock based on it.
> 
> - A user space program using the virtual clock synchronizes to within
>   100 nanoseconds of its upstream PTP Domain.  So far, so good.
> 
> - Now a second program using the physical clock starts up, and
>   proceeds to measure, then correct the gross phase offset to its
>   upstream PTP Domain.
> 
> - The driver must now add, as your proposal entails, the reverse
>   correction into the virtual clock's timecounter/cyclecounter.
> - However, this particular physical clock uses a RMW pattern to
>   program the offset correction.
> 
> - Boom.  Now the duration of the RMW becomes an offset error in the
>   virtual clock.  The magnitude may be microseconds or even
>   milliseconds for devices behind slow MDIO buses, for example.
> 

My proposal includes handling PHC offset entirely in software. There is
no way (and we agree on this :)) to change the PHC offset without
impacting children virtual clocks.

Done in software, an offset adjustment has no impact at all on virtual
clocks (since it can always be done atomically, not RMW).

So with, no hardware clock phase adjustment and limited frequency
adjustments, we believe it can be made fully transparent to virtual
clocks. And that would improve the current limitation of no adjustment
all, and would unblock the support of features like Qbv for devices
with a single clock.

Thanks,
Sebastien