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

[Jack Winch <sunt.un.morcov@xxxxxxxxx>]

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'.

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.

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