Re: [PATCH] ptp: Add PTP_CLOCK_EXTTSUSR internal ptp_event

[Jonathan Lemon <jonathan.lemon@gmail.com>]

On Wed, Jun 30, 2021 at 07:42:57AM -0700, Richard Cochran wrote:
> 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.

The current 'struct ptp_extts_event' returns 32 bytes to userspace
for every event.  Of these, 16 bytes (50%) are unused, as the structure
only returns a timestamp + index, without any event information.

It seems logical that these unused bytes (which are event specific)
could be used to convey more information about the event itself.


> 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 question whether the definition of "all-purpose" really applies
here.  All it tells me is that "an event happened on this channel 
at this time".

If the user doesn't care about additional data, it can just be 
ignored, right?


In the meantime, let's see what the HW guys say about doing the 
comparision in SW.  Other vendors have PPS input to their MAC,
so the disciplining is done in HW, bypassing adjphase() completely.
-- 
Jonathan