Hi Thomas,

Thank you for your suggestions.

On Thu, Feb 27, 2020 at 12:06:01AM +0100, Thomas Gleixner wrote:

Christopher,

"Christopher S. Hall" [off-list ref] writes:

quoted

On Fri, Jan 31, 2020 at 07:14:49PM +0100, Thomas Gleixner wrote:

quoted

christopher.s.hall@intel.com writes:

quoted

The TGPIO hardware doesn't implement interrupts. For TGPIO input, the
output edge-timestamp API is re-used to implement a user-space polling
interface. For periodic input (e.g. PPS) this is fairly efficient,
requiring only a marginally faster poll rate than the input event
frequency.

I really have a hard time to understand why this is implemented as part
of PTP while you talk about PPS at the same time.

We primarily need support for periodic input and output uses cases.
Apologies for omitting the periodic output use case from the cover
letter. While TGPIO isn't associated with a PTP timestamp clock, the PHC
pin/clock interface fits the usage otherwise.

Which usage? PTP like usage? I really have a hard time to make the
connection. PTP is as the name says a protocol to synchronize time
across a network.

What you're having is a GPIO which has some magic timestamp clock which
can be correlated back to ART/TSC, right?

Right.

quoted

The customer requested usages are 1 kHz and 1 Hz for both input and
output. Some higher level use cases are:
- using a GPS PPS signal to sync the system clock

That makes at least some sense. See below.

quoted

- auditing timesync precision for financial services, especially high
	frequency trading (e.g. MiFID).

A good reason to not support it at all. Aside of that I have no idea how
that auditing is supposed to work. Just throwing a few buzzwords around
is not giving much technical context.

quoted

Apart from clock import/export applications, timestamping single I/O
events are potentially valuable for industrial control applications
(e.g. motor position sensing vs. time). As time sync precision
requirements for these applications are tightened, standard GPIO
timing precision will not be good enough.

Well, coming from that industry I really doubt that you can do anything
useful with it, but hey it's been 25 years since I stopped working on
motor and motion controllers :)

Anyway, the device we are talking about is a GPIO device with inputs and
outputs plus bells and whistels attached to it.

On the input side this provides a timestamp taken by the hardware when
the input level changes, i.e. hardware based time stamping instead of
software based interrupt arrival timestamping. Looks like an obvious
extension to the GPIO subsystem.

How that timestamp is processed/converted and what an application can
actually do with it is a secondary problem:

  - PPS mode:

    This can be implemented as an actual PPS driver which consumes the
    GPIO, does timer based polling and feeds the timestamp into the PPS
    subsystem. Might be not the most accurate solution, so I can see why
    you want to use the PTP interface for it, which provides the raw
    clocksource (ART/TSC) and the correlated monotonic/realtime
    timestamps. But then again this wants to be a PTP driver consuming
    the GPIO and the timestamp via timer based polling.

  - GPIO sampling
  
    That's totally disconnected from PPS/PTP and just provides a
    correlated clock monotonic timestamp to the application.

    That covers your motor example :)

  - Timesync validation:

    -Enocluehowthatshouldworkatall

And of course you can use the GPIO input just as input without bells and
whistels :)

Now you have the output side which again is a GPIO in the first
place. But then it also has a secondary function which allows to create
a periodic output with a magic correlation to the ART and some way to
actually adjust the frequency. Neither of those two functions are in
anyway relatable to PTP AFAICT.

The periodic, programmable and adjustable output is pretty much a PWM of
some form and what you want to tell it is: Output a pulse at a given
frequency. Due to the fact that the input clock of that thing is ART you
can do the magic transformation from ART frequency to frequency adjusted
clock monotonic in order to tweak the parameters so they actually end up
generating your precise output frequency.  Tell the driver which
frequency you want and it retrieves the correlation information from the
kernel and uses it to achieve a precise output frequency. Doesn't sound
like rocket science and does not required new magic ioctls.

This will have a few touch points in the kernel - PWM, GPIO, PPS. I'll
work on an RFC patchset.

I might be missing something, but you surely can fill the blanks then.

Thanks,

        tglx

Thanks,
Christopher