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

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Mon, Oct 12, 2020 at 4:21 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
>
> On Mon, Oct 12, 2020 at 03:39:21PM +0200, Bartosz Golaszewski wrote:
> > On Mon, Oct 12, 2020 at 1:01 PM Jack Winch <sunt.un.morcov@xxxxxxxxx> wrote:
> > >
> >
> > [snip]
> >
> > >
> > > > We still haven't released uAPI v2 so I'm open to some last-minute
> > > > changes if they make sense (as you explained in the other email about
> > > > in-kernel timestamping) and are posted soon (before rc3-rc4). I'd like
> > > > to hear Arnd's opinion on this first though.
> > >
> > >
> > > What's the timescales for this?  As I would be doing this in a
> > > personal capacity, I will likely have to look at this over a couple of
> > > weeks.  I would also be limited to testing on an ARMv8 platform, as I
> > > currently have limited access to hardware.
> > >
> >
> > It would be 3-4 weeks from now.
> >
> > In terms of effort: it doesn't look too complicated. It looks like we
> > need to add a new flag to the uAPI:
> > GPIO_V2_LINE_FLAG_EDGE_CLOCK_REALTIME which would make the edge
> > detector use the real-time clock. I wouldn't stress too much about the
> > performance of obtaining the timestamp - it's probably negligible
> > compared to passing the event struct over to user-space.
> >
> > Kent does the above look right?
> >
>
> Could we make that GPIO_V2_LINE_FLAG_EVENT_CLOCK_REALTIME, as it
> controls the source of the timestamp in struct gpio_v2_line_event?
>

Sure, even better!

> Otherwise I don't see any problem with it, and I can have a patch out in
> a day or two.
>
> Cheers,
> Kent.

Bartosz