Re: Suggestion - Configurable Source Clock Type for Line Event Timestamping

[Kent Gibson <warthog618@gmail.com>]

On Mon, Oct 12, 2020 at 08:23:09AM +0100, Jack Winch wrote:
> Hi Kent,
> 
> Thanks for the quick response. It was originally my intention to CC
> the pair of you on my original email, but I wasn't sure if it was 'the
> done thing'.
> 

It probably couldn't hurt, as would prefixing your subject with
[libgpiod] if it is only relevant to the chardev and libgpiod.

And including the relevant sections of the mail you are replying to helps
as well.

> For most of the users I previously referred to, minimum timestamping
> latency (using the realtime clock as the source) is crucial. A
> userspace solution might be suitable for the others, but for these
> wall clock time sensitive applications the acquisition of a timestamp
> value from the system realtime clock is required within the interrupt
> handling code.
> 
> For context, these wall clock time sensitive users are running on
> systems which are PTPv2 clients, with their system realtime clock
> synchronised to that of a local PTP Grand Master clock.  In the past,
> I have used the TTL Pulse Per Second (PPS) output of the Grand Master
> to evaluate methods of timestamping line events with wall clock time
> and it was the kernel timestamping which was most suitable for our
> application.
> 

So a mapping from the MONOTONIC timestamp, taken in the ISR and returned
in the event, to the equivalent REALTIME timestamp is not reliable as
there is jitter between the two clocks?

Cheers,
Kent.

> Another way to skin the cat could be to create separate kernel modules
> for these applications, with them acting as a consumer to the GPIO
> subsystem.  That way, interrupts could be setup and handled for line
> events, with these application specific kernel modules undertaking the
> timestamping using the realtime system clock within the module ISRs.
> But that would have to be assessed.
> 
> I still believe adding this functionality to the chardev would be
> beneficial for users, although I understand your preference for other
> solutions first.
> 
> Regarding the extending of the flags field, you're absolutely right.
> One thing I'd have to go over is how changes to the use of that flag
> field could effect other parts of the subsystem.  I would expect that
> this change will only be utilised by the chardev in the first instance
> however.
> 
> I also have a couple of other queries regarding the current and future
> state of libgpiod, but I will submit those via a separate thread of
> discussion in order to keep each discussion appropriately partitioned.
> 
> Thanks,
> Jack