Re: [RFCv3 API PATCH 15/31] v4l2-core: Add new V4L2_CAP_MONOTONIC_TS capability.

["Daniel Glöckner" <daniel-gl@gmx.net>]

On Sun, Sep 16, 2012 at 11:59:42PM +0200, Sylwester Nawrocki wrote:
> On 09/16/2012 05:33 PM, Laurent Pinchart wrote:
> > On Sunday 16 September 2012 15:57:14 Hans Verkuil wrote:
> >> On Sat September 15 2012 22:16:24 Sylwester Nawrocki wrote:
> >>> There is already lots of overhead related to the buffers management, could
> >>> we perhaps have the most common option defined in a way that drivers don't
> >>> need to update each buffer's flags before dequeuing, only to indicate the
> >>> timestamp type (other than flags being modified in videobuf) ?
> >>
> >> Well, if all vb2 drivers use the monotonic clock, then you could do it in
> >> __fill_v4l2_buffer: instead of clearing just the state flags you'd clear
> >> state + clock flags, and you OR in the monotonic flag in the case statement
> >> below (adding just a single b->flags |= line in the DEQUEUED case).
> >>
> >> So that wouldn't add any overhead. Not that I think setting a flag will add
> >> any measurable overhead in any case.
> 
> Yes, that might be indeed negligible overhead, especially if it's done well.
> User space logic usually adds much more to complexity.
> 
> Might be good idea to add some helpers to videobuf2, so handling timestamps
> is as simple as possible in drivers.

The kernel keeps the time of the last timer interrupt in
timekeeper.xtime_sec and timekeeper.xtime_nsec in CLOCK_REALTIME,
so it just has to add the nanoseconds since then. Getting CLOCK_MONOTONIC
always involves adding timekeeper.wall_to_monotonic, so it is
a few cycles less overhead to get CLOCK_REALTIME.

How about storing both values and deferring the addition to
__fill_v4l2_buffer just for applications that want monotonic time?
I wouldn't justify this with the reduced overhead but with backward
compatibility.

  Daniel