Re: [PATCH] ptp: Add PTP_CLOCK_EXTTSUSR internal ptp_event

[Richard Cochran <richardcochran@gmail.com>]

On Tue, Jun 29, 2021 at 08:50:31PM -0700, Jonathan Lemon wrote:
> The PHC should be sync'd to the PPS coming from the GPS signal.
> However, the GPS may be in holdover, so the actual counter comes
> from an atomic oscillator.  As the oscillator may be ever so 
> slightly out of sync with the GPS (or drifts with temperature),
> so we need to measure the phase difference between the two and
> steer the oscillator slightly.
> 
> The phase comparision between the two signals is done in HW 
> with a phasemeter, for precise comparisons.  The actual phase
> steering/adjustment is done through adjphase().

So you don't need the time stamp itself, just the phase offset, right?

> What's missing is the ability to report the phase difference
> to user space so the adjustment can be performed.

So let's create an interface for that reporting.

> Since these events are channel specific, I don't see why
> this is problematic.  The code blocks in question from my
> upcoming patch (dependent on this) is:

The long standing policy is not to add new features that don't have
users.  It would certainly help me in review if I could see the entire
patch series.  Also, I wonder what the user space code looks like.

> I'm not seeing why this is controversial.

It is about getting the right interface.  The external time stamp
interface is generic and all-purpose, and so I question whether your
extension makes sense.

I guess from what you have explained so far that the:

- GPS produces a pulse on the full second.
- That pulse is time stamped in the PHC.
- The HW calculates the difference between the full second and the
  captured time.
- User space steers the PHC based on the difference.

If this is so, why not simply use the time stamp itself?  Or if the
extra number is a correction to the time stamp, why not apply the
correction to the time stamp?

Thanks,
Richard