[PATCH 0/4] Monotonic timestamps

[PATCH 0/4] Monotonic timestamps

[Sakari Ailus]

Hi all,

Here's my first monotonic timestamps patch series. Since the RFC series,
I've corrected a warning in drivers/media/usb/s2255/s2255drv.c that was
caused by an unused variable.

All affected drivers compile without warnings. I've tested this on the OMAP
3 ISP:

02:11:34 sailus@peruna [~]yavta -c1 -f SGBRG10 -F/tmp/foo -s 2864x2048 /dev/video1
Device /dev/video1 opened.
Device `OMAP3 ISP CSI2a output' on `media' is a video capture device.
Video format set: SGBRG10 (30314247) 2864x2048 (stride 5728) buffer size 11730944
Video format: SGBRG10 (30314247) 2864x2048 (stride 5728) buffer size 11730944
4 buffers requested.
length: 11730944 offset: 0 timestamp type: monotonic
Buffer 0 mapped at address 0xb62cb000.
length: 11730944 offset: 11730944 timestamp type: monotonic
Buffer 1 mapped at address 0xb579b000.
length: 11730944 offset: 23461888 timestamp type: monotonic
Buffer 2 mapped at address 0xb4c6b000.
length: 11730944 offset: 35192832 timestamp type: monotonic
Buffer 3 mapped at address 0xb413b000.
0 (0) [-] 0 11730944 bytes 310.791595 310.792083 13.331 fps
Captured 1 frames in 0.075500 seconds (13.244948 fps, 155375737.438942 B/s).
4 buffers released.

What the patches do is that they

1. Add new buffer flags for timestamp type, and a mask,
2. convert all the drivers to use monotonic timestamps and
3. tell that all drivers are using monotonic timestamps.

The assumption is that all drivers will use monotonic timestamps, especially
the timestamp type is set in videobuf(2) in drivers that use it. This could
be changed later on if we wish to make it selectable; in this case videobuf2
would need to be told, and the helper function v4l2_get_timestamp() would
need to be put to videobuf2 instead.

Comments and questions are very welcome!

Kind regards,

-- 
Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

[PATCH 1/4] v4l: Define video buffer flags for timestamp types

[Sakari Ailus]

Define video buffer flags for different timestamp types. Everything up to
now have used either realtime clock or monotonic clock, without a way to
tell which clock the timestamp was taken from.

Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 Documentation/DocBook/media/v4l/io.xml |   25 +++++++++++++++++++++++++
 include/uapi/linux/videodev2.h         |    4 ++++
 2 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml
index 7e2f3d7..d598f2c 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -938,6 +938,31 @@ Typically applications shall use this flag for output buffers if the data
 in this buffer has not been created by the CPU but by some DMA-capable unit,
 in which case caches have not been used.</entry>
 	  </row>
+	  <row>
+	    <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry>
+	    <entry>0xe000</entry>
+	    <entry>Mask for timestamp types below. To test the
+	    timestamp type, mask out bits not belonging to timestamp
+	    type by performing a logical and operation with buffer
+	    flags and timestamp mask.</tt> </entry>
+	  </row>
+	  <row>
+	    <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry>
+	    <entry>0x0000</entry>
+	    <entry>Unknown timestamp type. This type is used by
+	    drivers before Linux 3.8 and may be either monotonic (see
+	    below) or realtime. Monotonic clock has been favoured in
+	    embedded systems whereas most of the drivers use the
+	    realtime clock.</entry>
+	  </row>
+	  <row>
+	    <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC</constant></entry>
+	    <entry>0x2000</entry>
+	    <entry>The buffer timestamp has been taken from the
+	    <constant>CLOCK_MONOTONIC</constant> clock. To access the
+	    same clock outside V4L2, use <tt>clock_gettime(2)</tt>
+	    .</entry>
+	  </row>
 	</tbody>
       </tgroup>
     </table>
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 2fff7ff..410ea9f 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -686,6 +686,10 @@ struct v4l2_buffer {
 /* Cache handling flags */
 #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE	0x0800
 #define V4L2_BUF_FLAG_NO_CACHE_CLEAN		0x1000
+/* Timestamp type */
+#define V4L2_BUF_FLAG_TIMESTAMP_MASK		0xe000
+#define V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN		0x0000
+#define V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC	0x2000
 
 /*
  *	O V E R L A Y   P R E V I E W
-- 
1.7.2.5

Re: [PATCH 1/4] v4l: Define video buffer flags for timestamp types

[Hans Verkuil]

On Thu November 15 2012 23:06:44 Sakari Ailus wrote:
> Define video buffer flags for different timestamp types. Everything up to
> now have used either realtime clock or monotonic clock, without a way to
> tell which clock the timestamp was taken from.
> 
> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
>  Documentation/DocBook/media/v4l/io.xml |   25 +++++++++++++++++++++++++
>  include/uapi/linux/videodev2.h         |    4 ++++
>  2 files changed, 29 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml
> index 7e2f3d7..d598f2c 100644
> --- a/Documentation/DocBook/media/v4l/io.xml
> +++ b/Documentation/DocBook/media/v4l/io.xml
> @@ -938,6 +938,31 @@ Typically applications shall use this flag for output buffers if the data
>  in this buffer has not been created by the CPU but by some DMA-capable unit,
>  in which case caches have not been used.</entry>
>  	  </row>
> +	  <row>
> +	    <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry>
> +	    <entry>0xe000</entry>
> +	    <entry>Mask for timestamp types below. To test the
> +	    timestamp type, mask out bits not belonging to timestamp
> +	    type by performing a logical and operation with buffer
> +	    flags and timestamp mask.</tt> </entry>
> +	  </row>
> +	  <row>
> +	    <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry>
> +	    <entry>0x0000</entry>
> +	    <entry>Unknown timestamp type. This type is used by
> +	    drivers before Linux 3.8 and may be either monotonic (see
> +	    below) or realtime. Monotonic clock has been favoured in
> +	    embedded systems whereas most of the drivers use the
> +	    realtime clock.</entry>

Isn't 'wallclock time' a better expression? It is probably a good idea as well
to add the userspace call that gives the same clock: gettimeofday or
clock_gettime(CLOCK_REALTIME) for the wallclock time and clock_gettime(CLOCK_MONOTONIC)
for the monotonic time. That way apps can do the same call and compare it to the
timestamp received.

> +	  </row>
> +	  <row>
> +	    <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC</constant></entry>
> +	    <entry>0x2000</entry>
> +	    <entry>The buffer timestamp has been taken from the
> +	    <constant>CLOCK_MONOTONIC</constant> clock. To access the
> +	    same clock outside V4L2, use <tt>clock_gettime(2)</tt>

Ah, you mentioned it here already for the monotonic clock :-)

> +	    .</entry>
> +	  </row>
>  	</tbody>
>        </tgroup>
>      </table>
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 2fff7ff..410ea9f 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -686,6 +686,10 @@ struct v4l2_buffer {
>  /* Cache handling flags */
>  #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE	0x0800
>  #define V4L2_BUF_FLAG_NO_CACHE_CLEAN		0x1000
> +/* Timestamp type */
> +#define V4L2_BUF_FLAG_TIMESTAMP_MASK		0xe000
> +#define V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN		0x0000
> +#define V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC	0x2000
>  
>  /*
>   *	O V E R L A Y   P R E V I E W
> 

Regards,

	Hans

Re: [PATCH 1/4] v4l: Define video buffer flags for timestamp types

[Sakari Ailus]

Hi Hans,

Thanks for the comments!

On Fri, Nov 16, 2012 at 02:51:29PM +0100, Hans Verkuil wrote:
> On Thu November 15 2012 23:06:44 Sakari Ailus wrote:
> > diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml
> > index 7e2f3d7..d598f2c 100644
> > --- a/Documentation/DocBook/media/v4l/io.xml
> > +++ b/Documentation/DocBook/media/v4l/io.xml
> > @@ -938,6 +938,31 @@ Typically applications shall use this flag for output buffers if the data
> >  in this buffer has not been created by the CPU but by some DMA-capable unit,
> >  in which case caches have not been used.</entry>
> >  	  </row>
> > +	  <row>
> > +	    <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry>
> > +	    <entry>0xe000</entry>
> > +	    <entry>Mask for timestamp types below. To test the
> > +	    timestamp type, mask out bits not belonging to timestamp
> > +	    type by performing a logical and operation with buffer
> > +	    flags and timestamp mask.</tt> </entry>
> > +	  </row>
> > +	  <row>
> > +	    <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry>
> > +	    <entry>0x0000</entry>
> > +	    <entry>Unknown timestamp type. This type is used by
> > +	    drivers before Linux 3.8 and may be either monotonic (see
> > +	    below) or realtime. Monotonic clock has been favoured in
> > +	    embedded systems whereas most of the drivers use the
> > +	    realtime clock.</entry>
> 
> Isn't 'wallclock time' a better expression? It is probably a good idea as
> well to add the userspace call that gives the same clock: gettimeofday or
> clock_gettime(CLOCK_REALTIME) for the wallclock time and
> clock_gettime(CLOCK_MONOTONIC) for the monotonic time. That way apps can
> do the same call and compare it to the timestamp received.

I'll add a reference to clock_gettime() and change realtime to wall clock
time. I wonder if I should also add that the unknown timestamp means either
of the two, or can we allow different kinds of unknown timestamps in the
future. Probably we should limit this to realtime and monotonic.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

Re: [PATCH 1/4] v4l: Define video buffer flags for timestamp types

[Hans Verkuil]

On Fri November 16 2012 16:20:03 Sakari Ailus wrote:
> Hi Hans,
> 
> Thanks for the comments!
> 
> On Fri, Nov 16, 2012 at 02:51:29PM +0100, Hans Verkuil wrote:
> > On Thu November 15 2012 23:06:44 Sakari Ailus wrote:
> > > diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml
> > > index 7e2f3d7..d598f2c 100644
> > > --- a/Documentation/DocBook/media/v4l/io.xml
> > > +++ b/Documentation/DocBook/media/v4l/io.xml
> > > @@ -938,6 +938,31 @@ Typically applications shall use this flag for output buffers if the data
> > >  in this buffer has not been created by the CPU but by some DMA-capable unit,
> > >  in which case caches have not been used.</entry>
> > >  	  </row>
> > > +	  <row>
> > > +	    <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry>
> > > +	    <entry>0xe000</entry>
> > > +	    <entry>Mask for timestamp types below. To test the
> > > +	    timestamp type, mask out bits not belonging to timestamp
> > > +	    type by performing a logical and operation with buffer
> > > +	    flags and timestamp mask.</tt> </entry>
> > > +	  </row>
> > > +	  <row>
> > > +	    <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry>
> > > +	    <entry>0x0000</entry>
> > > +	    <entry>Unknown timestamp type. This type is used by
> > > +	    drivers before Linux 3.8 and may be either monotonic (see
> > > +	    below) or realtime. Monotonic clock has been favoured in
> > > +	    embedded systems whereas most of the drivers use the
> > > +	    realtime clock.</entry>
> > 
> > Isn't 'wallclock time' a better expression? It is probably a good idea as
> > well to add the userspace call that gives the same clock: gettimeofday or
> > clock_gettime(CLOCK_REALTIME) for the wallclock time and
> > clock_gettime(CLOCK_MONOTONIC) for the monotonic time. That way apps can
> > do the same call and compare it to the timestamp received.
> 
> I'll add a reference to clock_gettime() and change realtime to wall clock
> time. I wonder if I should also add that the unknown timestamp means either
> of the two, or can we allow different kinds of unknown timestamps in the
> future.

No. UNKNOWN should never be used in the future. It is specific to the pre
timestamp flag era where the timestamp is really only one of two options.

Regards,

	Hans

[PATCH v1.1 1/4] v4l: Define video buffer flags for timestamp types

[Sakari Ailus]

Define video buffer flags for different timestamp types. Everything up to
now have used either realtime clock or monotonic clock, without a way to
tell which clock the timestamp was taken from.

Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
Changes since v1:

- Mention about timestamps in API changes
- Bump API version to 3.8
- DocBook compile fixes
- Tell realtime clock is the same as wall clock, and mention how to get such
  timestamps in the user space

 Documentation/DocBook/media/v4l/compat.xml |   12 +++++++++++
 Documentation/DocBook/media/v4l/io.xml     |   29 ++++++++++++++++++++++++++++
 Documentation/DocBook/media/v4l/v4l2.xml   |   12 ++++++++++-
 include/uapi/linux/videodev2.h             |    4 +++
 4 files changed, 56 insertions(+), 1 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml
index 4fdf6b5..651ca52 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2477,6 +2477,18 @@ that used it. It was originally scheduled for removal in 2.6.35.
       </orderedlist>
     </section>
 
+    <section>
+      <title>V4L2 in Linux 3.8</title>
+      <orderedlist>
+        <listitem>
+	  <para>Added timestamp types to
+	  <structfield>flags</structfield> field in
+	  <structname>v4l2_buffer</structname>. See <xref
+	  linkend="buffer-flags" />.</para>
+        </listitem>
+      </orderedlist>
+    </section>
+
     <section id="other">
       <title>Relation of V4L2 to other Linux multimedia APIs</title>
 
diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml
index 7e2f3d7..bcd1c8f7 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -938,6 +938,35 @@ Typically applications shall use this flag for output buffers if the data
 in this buffer has not been created by the CPU but by some DMA-capable unit,
 in which case caches have not been used.</entry>
 	  </row>
+	  <row>
+	    <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry>
+	    <entry>0xe000</entry>
+	    <entry>Mask for timestamp types below. To test the
+	    timestamp type, mask out bits not belonging to timestamp
+	    type by performing a logical and operation with buffer
+	    flags and timestamp mask.</entry>
+	  </row>
+	  <row>
+	    <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry>
+	    <entry>0x0000</entry>
+	    <entry>Unknown timestamp type. This type is used by
+	    drivers before Linux 3.8 and may be either monotonic (see
+	    below) or realtime (wall clock). Monotonic clock has been
+	    favoured in embedded systems whereas most of the drivers
+	    use the realtime clock. Either kinds of timestamps are
+	    available in user space via
+	    <function>clock_gettime(2)</function> using clock IDs
+	    <constant>CLOCK_MONOTONIC</constant> and
+	    <constant>CLOCK_REALTIME</constant>, respectively.</entry>
+	  </row>
+	  <row>
+	    <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC</constant></entry>
+	    <entry>0x2000</entry>
+	    <entry>The buffer timestamp has been taken from the
+	    <constant>CLOCK_MONOTONIC</constant> clock. To access the
+	    same clock outside V4L2, use
+	    <function>clock_gettime(2)</function> .</entry>
+	  </row>
 	</tbody>
       </tgroup>
     </table>
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml
index 10ccde9..8b6f29e 100644
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -140,6 +140,16 @@ structs, ioctls) must be noted in more detail in the history chapter
 applications. -->
 
       <revision>
+	<revnumber>3.8</revnumber>
+	<date>2012-11-16</date>
+	<authorinitials>sa</authorinitials>
+	<revremark>Added timestamp types to
+	<structname>v4l2_buffer</structname>, see <xref
+	linkend="buffer-flags" />.
+	</revremark>
+      </revision>
+
+      <revision>
 	<revnumber>3.6</revnumber>
 	<date>2012-07-02</date>
 	<authorinitials>hv</authorinitials>
@@ -472,7 +482,7 @@ and discussions on the V4L mailing list.</revremark>
 </partinfo>
 
 <title>Video for Linux Two API Specification</title>
- <subtitle>Revision 3.6</subtitle>
+ <subtitle>Revision 3.8</subtitle>
 
   <chapter id="common">
     &sub-common;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 2fff7ff..410ea9f 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -686,6 +686,10 @@ struct v4l2_buffer {
 /* Cache handling flags */
 #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE	0x0800
 #define V4L2_BUF_FLAG_NO_CACHE_CLEAN		0x1000
+/* Timestamp type */
+#define V4L2_BUF_FLAG_TIMESTAMP_MASK		0xe000
+#define V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN		0x0000
+#define V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC	0x2000
 
 /*
  *	O V E R L A Y   P R E V I E W
-- 
1.7.2.5

[PATCH v1.2 1/4] v4l: Define video buffer flags for timestamp types

[Sakari Ailus]

Define video buffer flags for different timestamp types. Everything up to
now have used either realtime clock or monotonic clock, without a way to
tell which clock the timestamp was taken from.

Also document that the clock source of the timestamp in the timestamp field
depends on buffer flags.

Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
Since v1.1:

- Change the description of the timestamp field; say that the type of the
  timestamp is dependent on the flags field.

 Documentation/DocBook/media/v4l/compat.xml |   12 ++++++
 Documentation/DocBook/media/v4l/io.xml     |   53 ++++++++++++++++++++++------
 Documentation/DocBook/media/v4l/v4l2.xml   |   12 ++++++-
 include/uapi/linux/videodev2.h             |    4 ++
 4 files changed, 69 insertions(+), 12 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml
index 4fdf6b5..651ca52 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2477,6 +2477,18 @@ that used it. It was originally scheduled for removal in 2.6.35.
       </orderedlist>
     </section>
 
+    <section>
+      <title>V4L2 in Linux 3.8</title>
+      <orderedlist>
+        <listitem>
+	  <para>Added timestamp types to
+	  <structfield>flags</structfield> field in
+	  <structname>v4l2_buffer</structname>. See <xref
+	  linkend="buffer-flags" />.</para>
+        </listitem>
+      </orderedlist>
+    </section>
+
     <section id="other">
       <title>Relation of V4L2 to other Linux multimedia APIs</title>
 
diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml
index 7e2f3d7..1243fa1 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -582,17 +582,19 @@ applications when an output stream.</entry>
 	    <entry>struct timeval</entry>
 	    <entry><structfield>timestamp</structfield></entry>
 	    <entry></entry>
-	    <entry><para>For input streams this is the
-system time (as returned by the <function>gettimeofday()</function>
-function) when the first data byte was captured. For output streams
-the data will not be displayed before this time, secondary to the
-nominal frame rate determined by the current video standard in
-enqueued order. Applications can for example zero this field to
-display frames as soon as possible. The driver stores the time at
-which the first data byte was actually sent out in the
-<structfield>timestamp</structfield> field. This permits
-applications to monitor the drift between the video and system
-clock.</para></entry>
+	    <entry><para>For input streams this is time when the first data
+	    byte was captured, as returned by the
+	    <function>clock_gettime()</function> function for the relevant
+	    clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in
+	    <xref linkend="buffer-flags" />. For output streams the data
+	    will not be displayed before this time, secondary to the nominal
+	    frame rate determined by the current video standard in enqueued
+	    order. Applications can for example zero this field to display
+	    frames as soon as possible. The driver stores the time at which
+	    the first data byte was actually sent out in the
+	    <structfield>timestamp</structfield> field. This permits
+	    applications to monitor the drift between the video and system
+	    clock.</para></entry>
 	  </row>
 	  <row>
 	    <entry>&v4l2-timecode;</entry>
@@ -938,6 +940,35 @@ Typically applications shall use this flag for output buffers if the data
 in this buffer has not been created by the CPU but by some DMA-capable unit,
 in which case caches have not been used.</entry>
 	  </row>
+	  <row>
+	    <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry>
+	    <entry>0xe000</entry>
+	    <entry>Mask for timestamp types below. To test the
+	    timestamp type, mask out bits not belonging to timestamp
+	    type by performing a logical and operation with buffer
+	    flags and timestamp mask.</entry>
+	  </row>
+	  <row>
+	    <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry>
+	    <entry>0x0000</entry>
+	    <entry>Unknown timestamp type. This type is used by
+	    drivers before Linux 3.8 and may be either monotonic (see
+	    below) or realtime (wall clock). Monotonic clock has been
+	    favoured in embedded systems whereas most of the drivers
+	    use the realtime clock. Either kinds of timestamps are
+	    available in user space via
+	    <function>clock_gettime(2)</function> using clock IDs
+	    <constant>CLOCK_MONOTONIC</constant> and
+	    <constant>CLOCK_REALTIME</constant>, respectively.</entry>
+	  </row>
+	  <row>
+	    <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC</constant></entry>
+	    <entry>0x2000</entry>
+	    <entry>The buffer timestamp has been taken from the
+	    <constant>CLOCK_MONOTONIC</constant> clock. To access the
+	    same clock outside V4L2, use
+	    <function>clock_gettime(2)</function> .</entry>
+	  </row>
 	</tbody>
       </tgroup>
     </table>
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml
index 10ccde9..8b6f29e 100644
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -140,6 +140,16 @@ structs, ioctls) must be noted in more detail in the history chapter
 applications. -->
 
       <revision>
+	<revnumber>3.8</revnumber>
+	<date>2012-11-16</date>
+	<authorinitials>sa</authorinitials>
+	<revremark>Added timestamp types to
+	<structname>v4l2_buffer</structname>, see <xref
+	linkend="buffer-flags" />.
+	</revremark>
+      </revision>
+
+      <revision>
 	<revnumber>3.6</revnumber>
 	<date>2012-07-02</date>
 	<authorinitials>hv</authorinitials>
@@ -472,7 +482,7 @@ and discussions on the V4L mailing list.</revremark>
 </partinfo>
 
 <title>Video for Linux Two API Specification</title>
- <subtitle>Revision 3.6</subtitle>
+ <subtitle>Revision 3.8</subtitle>
 
   <chapter id="common">
     &sub-common;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 2fff7ff..410ea9f 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -686,6 +686,10 @@ struct v4l2_buffer {
 /* Cache handling flags */
 #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE	0x0800
 #define V4L2_BUF_FLAG_NO_CACHE_CLEAN		0x1000
+/* Timestamp type */
+#define V4L2_BUF_FLAG_TIMESTAMP_MASK		0xe000
+#define V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN		0x0000
+#define V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC	0x2000
 
 /*
  *	O V E R L A Y   P R E V I E W
-- 
1.7.2.5

Re: [PATCH v1.2 1/4] v4l: Define video buffer flags for timestamp types

[Hans Verkuil]

On Wed November 21 2012 20:13:22 Sakari Ailus wrote:
> Define video buffer flags for different timestamp types. Everything up to
> now have used either realtime clock or monotonic clock, without a way to
> tell which clock the timestamp was taken from.
> 
> Also document that the clock source of the timestamp in the timestamp field
> depends on buffer flags.
> 
> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Acked-by: Hans Verkuil <hans.verkuil@cisco.com>

But see my comments below for a separate matter...

> ---
> Since v1.1:
> 
> - Change the description of the timestamp field; say that the type of the
>   timestamp is dependent on the flags field.
> 
>  Documentation/DocBook/media/v4l/compat.xml |   12 ++++++
>  Documentation/DocBook/media/v4l/io.xml     |   53 ++++++++++++++++++++++------
>  Documentation/DocBook/media/v4l/v4l2.xml   |   12 ++++++-
>  include/uapi/linux/videodev2.h             |    4 ++
>  4 files changed, 69 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml
> index 4fdf6b5..651ca52 100644
> --- a/Documentation/DocBook/media/v4l/compat.xml
> +++ b/Documentation/DocBook/media/v4l/compat.xml
> @@ -2477,6 +2477,18 @@ that used it. It was originally scheduled for removal in 2.6.35.
>        </orderedlist>
>      </section>
>  
> +    <section>
> +      <title>V4L2 in Linux 3.8</title>
> +      <orderedlist>
> +        <listitem>
> +	  <para>Added timestamp types to
> +	  <structfield>flags</structfield> field in
> +	  <structname>v4l2_buffer</structname>. See <xref
> +	  linkend="buffer-flags" />.</para>
> +        </listitem>
> +      </orderedlist>
> +    </section>
> +
>      <section id="other">
>        <title>Relation of V4L2 to other Linux multimedia APIs</title>
>  
> diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml
> index 7e2f3d7..1243fa1 100644
> --- a/Documentation/DocBook/media/v4l/io.xml
> +++ b/Documentation/DocBook/media/v4l/io.xml
> @@ -582,17 +582,19 @@ applications when an output stream.</entry>
>  	    <entry>struct timeval</entry>
>  	    <entry><structfield>timestamp</structfield></entry>
>  	    <entry></entry>
> -	    <entry><para>For input streams this is the
> -system time (as returned by the <function>gettimeofday()</function>
> -function) when the first data byte was captured. For output streams
> -the data will not be displayed before this time, secondary to the
> -nominal frame rate determined by the current video standard in
> -enqueued order. Applications can for example zero this field to
> -display frames as soon as possible. The driver stores the time at
> -which the first data byte was actually sent out in the
> -<structfield>timestamp</structfield> field. This permits
> -applications to monitor the drift between the video and system
> -clock.</para></entry>
> +	    <entry><para>For input streams this is time when the first data
> +	    byte was captured,

What should we do with this? In most drivers the timestamp is actually the
time that the *last* byte was captured. The reality is that the application
doesn't know whether it is the first or the last.

One option is to add a new flag for this, or to leave it open. The last
makes me uncomfortable, since there can be quite a difference between the
time of the first or last byte, and that definitely has an effect on the
A/V sync.

This is a separate topic that should be handled in a separate patch, but I
do think we need to take a closer look at this.

> as returned by the
> +	    <function>clock_gettime()</function> function for the relevant
> +	    clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in
> +	    <xref linkend="buffer-flags" />. For output streams the data
> +	    will not be displayed before this time, secondary to the nominal
> +	    frame rate determined by the current video standard in enqueued
> +	    order. Applications can for example zero this field to display
> +	    frames as soon as possible.

There is not a single driver that supports this feature. There is also no
way an application can query the driver whether this feature is supported.
Personally I don't think this should be the task of a driver anyway: if you
want to postpone displaying a frame, then just wait before calling QBUF.
Don't add complicated logic in drivers/vb2 where it needs to hold buffers
back if the time hasn't been reached yet.

What might be much more interesting for output devices is if the timestamp
field is filled in with the expected display time on return of QBUF. That
would be very useful for regulating the flow of new frames.

What do you think?

> The driver stores the time at which
> +	    the first data byte was actually sent out in the
> +	    <structfield>timestamp</structfield> field.

Same problem as with the capture time: does the timestamp refer to the first
or last byte that's sent out? I think all output drivers set it to the time
of the last byte (== when the DMA of the frame is finished).

Regards,

	Hans

> This permits
> +	    applications to monitor the drift between the video and system
> +	    clock.</para></entry>
>  	  </row>
>  	  <row>
>  	    <entry>&v4l2-timecode;</entry>
> @@ -938,6 +940,35 @@ Typically applications shall use this flag for output buffers if the data
>  in this buffer has not been created by the CPU but by some DMA-capable unit,
>  in which case caches have not been used.</entry>
>  	  </row>
> +	  <row>
> +	    <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry>
> +	    <entry>0xe000</entry>
> +	    <entry>Mask for timestamp types below. To test the
> +	    timestamp type, mask out bits not belonging to timestamp
> +	    type by performing a logical and operation with buffer
> +	    flags and timestamp mask.</entry>
> +	  </row>
> +	  <row>
> +	    <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry>
> +	    <entry>0x0000</entry>
> +	    <entry>Unknown timestamp type. This type is used by
> +	    drivers before Linux 3.8 and may be either monotonic (see
> +	    below) or realtime (wall clock). Monotonic clock has been
> +	    favoured in embedded systems whereas most of the drivers
> +	    use the realtime clock. Either kinds of timestamps are
> +	    available in user space via
> +	    <function>clock_gettime(2)</function> using clock IDs
> +	    <constant>CLOCK_MONOTONIC</constant> and
> +	    <constant>CLOCK_REALTIME</constant>, respectively.</entry>
> +	  </row>
> +	  <row>
> +	    <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC</constant></entry>
> +	    <entry>0x2000</entry>
> +	    <entry>The buffer timestamp has been taken from the
> +	    <constant>CLOCK_MONOTONIC</constant> clock. To access the
> +	    same clock outside V4L2, use
> +	    <function>clock_gettime(2)</function> .</entry>
> +	  </row>
>  	</tbody>
>        </tgroup>
>      </table>
> diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml
> index 10ccde9..8b6f29e 100644
> --- a/Documentation/DocBook/media/v4l/v4l2.xml
> +++ b/Documentation/DocBook/media/v4l/v4l2.xml
> @@ -140,6 +140,16 @@ structs, ioctls) must be noted in more detail in the history chapter
>  applications. -->
>  
>        <revision>
> +	<revnumber>3.8</revnumber>
> +	<date>2012-11-16</date>
> +	<authorinitials>sa</authorinitials>
> +	<revremark>Added timestamp types to
> +	<structname>v4l2_buffer</structname>, see <xref
> +	linkend="buffer-flags" />.
> +	</revremark>
> +      </revision>
> +
> +      <revision>
>  	<revnumber>3.6</revnumber>
>  	<date>2012-07-02</date>
>  	<authorinitials>hv</authorinitials>
> @@ -472,7 +482,7 @@ and discussions on the V4L mailing list.</revremark>
>  </partinfo>
>  
>  <title>Video for Linux Two API Specification</title>
> - <subtitle>Revision 3.6</subtitle>
> + <subtitle>Revision 3.8</subtitle>
>  
>    <chapter id="common">
>      &sub-common;
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 2fff7ff..410ea9f 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -686,6 +686,10 @@ struct v4l2_buffer {
>  /* Cache handling flags */
>  #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE	0x0800
>  #define V4L2_BUF_FLAG_NO_CACHE_CLEAN		0x1000
> +/* Timestamp type */
> +#define V4L2_BUF_FLAG_TIMESTAMP_MASK		0xe000
> +#define V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN		0x0000
> +#define V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC	0x2000
>  
>  /*
>   *	O V E R L A Y   P R E V I E W
> 

Re: [PATCH v1.2 1/4] v4l: Define video buffer flags for timestamp types

[Sakari Ailus]

Hi Hans,

On Wed, Nov 21, 2012 at 11:53:02PM +0100, Hans Verkuil wrote:
> On Wed November 21 2012 20:13:22 Sakari Ailus wrote:
> > Define video buffer flags for different timestamp types. Everything up to
> > now have used either realtime clock or monotonic clock, without a way to
> > tell which clock the timestamp was taken from.
> > 
> > Also document that the clock source of the timestamp in the timestamp field
> > depends on buffer flags.
> > 
> > Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
> > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> 
> Acked-by: Hans Verkuil <hans.verkuil@cisco.com>

Thanks! :-)

> But see my comments below for a separate matter...
> 
> > ---
> > Since v1.1:
> > 
> > - Change the description of the timestamp field; say that the type of the
> >   timestamp is dependent on the flags field.
> > 
> >  Documentation/DocBook/media/v4l/compat.xml |   12 ++++++
> >  Documentation/DocBook/media/v4l/io.xml     |   53 ++++++++++++++++++++++------
> >  Documentation/DocBook/media/v4l/v4l2.xml   |   12 ++++++-
> >  include/uapi/linux/videodev2.h             |    4 ++
> >  4 files changed, 69 insertions(+), 12 deletions(-)
> > 
> > diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml
> > index 4fdf6b5..651ca52 100644
> > --- a/Documentation/DocBook/media/v4l/compat.xml
> > +++ b/Documentation/DocBook/media/v4l/compat.xml
> > @@ -2477,6 +2477,18 @@ that used it. It was originally scheduled for removal in 2.6.35.
> >        </orderedlist>
> >      </section>
> >  
> > +    <section>
> > +      <title>V4L2 in Linux 3.8</title>
> > +      <orderedlist>
> > +        <listitem>
> > +	  <para>Added timestamp types to
> > +	  <structfield>flags</structfield> field in
> > +	  <structname>v4l2_buffer</structname>. See <xref
> > +	  linkend="buffer-flags" />.</para>
> > +        </listitem>
> > +      </orderedlist>
> > +    </section>
> > +
> >      <section id="other">
> >        <title>Relation of V4L2 to other Linux multimedia APIs</title>
> >  
> > diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml
> > index 7e2f3d7..1243fa1 100644
> > --- a/Documentation/DocBook/media/v4l/io.xml
> > +++ b/Documentation/DocBook/media/v4l/io.xml
> > @@ -582,17 +582,19 @@ applications when an output stream.</entry>
> >  	    <entry>struct timeval</entry>
> >  	    <entry><structfield>timestamp</structfield></entry>
> >  	    <entry></entry>
> > -	    <entry><para>For input streams this is the
> > -system time (as returned by the <function>gettimeofday()</function>
> > -function) when the first data byte was captured. For output streams
> > -the data will not be displayed before this time, secondary to the
> > -nominal frame rate determined by the current video standard in
> > -enqueued order. Applications can for example zero this field to
> > -display frames as soon as possible. The driver stores the time at
> > -which the first data byte was actually sent out in the
> > -<structfield>timestamp</structfield> field. This permits
> > -applications to monitor the drift between the video and system
> > -clock.</para></entry>
> > +	    <entry><para>For input streams this is time when the first data
> > +	    byte was captured,
> 
> What should we do with this? In most drivers the timestamp is actually the
> time that the *last* byte was captured. The reality is that the application
> doesn't know whether it is the first or the last.
> 
> One option is to add a new flag for this, or to leave it open. The last
> makes me uncomfortable, since there can be quite a difference between the
> time of the first or last byte, and that definitely has an effect on the
> A/V sync.

Very true. I'd also prefer to have this defined so the information would be
available to the user space.

> This is a separate topic that should be handled in a separate patch, but I
> do think we need to take a closer look at this.

I'm not against one more buffer flag to tell which one it is. :-)

There are hardly any other options than the frame start and frame end.

On the other hand, the FRAME_SYNC event is supported by some drivers and
that can be used to obtain the timestamp from frame start. Not all drivers
support it nor the applications can be expected to use this just to get a
timestamp, though.

> > as returned by the
> > +	    <function>clock_gettime()</function> function for the relevant
> > +	    clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in
> > +	    <xref linkend="buffer-flags" />. For output streams the data
> > +	    will not be displayed before this time, secondary to the nominal
> > +	    frame rate determined by the current video standard in enqueued
> > +	    order. Applications can for example zero this field to display
> > +	    frames as soon as possible.
> 
> There is not a single driver that supports this feature. There is also no
> way an application can query the driver whether this feature is supported.
> Personally I don't think this should be the task of a driver anyway: if you
> want to postpone displaying a frame, then just wait before calling QBUF.
> Don't add complicated logic in drivers/vb2 where it needs to hold buffers
> back if the time hasn't been reached yet.

Assuming realtime clock, there could be some interesting interactions with
this and daylight saving time or setting system clock, for example.

I'm definitely not against removing this, especially as no driver uses it.

> What might be much more interesting for output devices is if the timestamp
> field is filled in with the expected display time on return of QBUF. That
> would be very useful for regulating the flow of new frames.
> 
> What do you think?

Fine for me. Sylwester also brought memory-to-memory devices (and
memory-to-memory processing whether the device is classified as such in API
or not) to my attention. For those devices it likely wouldn't matter at all
what's the system time when the frame is processed since the frame wasn't
captured at that time anyway.

In those cases it might makes sense to use timestamp that e.g. comes from
the compressed stream, or pass encoder timestamps that are going to be part
of the compressed stream. I think MPEG-related use cases were briefly
mentioned in the timestamp discussion earlier.

> > The driver stores the time at which
> > +	    the first data byte was actually sent out in the
> > +	    <structfield>timestamp</structfield> field.
> 
> Same problem as with the capture time: does the timestamp refer to the first
> or last byte that's sent out? I think all output drivers set it to the time
> of the last byte (== when the DMA of the frame is finished).

I haven't actually even seen a capture driver that would do otherwise, but
that could be just me not knowing many enough. :-) Would we actually break
something if we changed the definition to say that this is the timestamp
taken when the frame is done?

-- 
Cheers,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

Re: [PATCH v1.2 1/4] v4l: Define video buffer flags for timestamp types

[Laurent Pinchart]

Hello,

On Thursday 22 November 2012 01:59:00 Sakari Ailus wrote:
> On Wed, Nov 21, 2012 at 11:53:02PM +0100, Hans Verkuil wrote:
> > On Wed November 21 2012 20:13:22 Sakari Ailus wrote:
> > > Define video buffer flags for different timestamp types. Everything up
> > > to now have used either realtime clock or monotonic clock, without a way
> > > to tell which clock the timestamp was taken from.
> > > 
> > > Also document that the clock source of the timestamp in the timestamp
> > > field depends on buffer flags.
> > > 
> > > Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
> > > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > 
> > Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
> 
> Thanks! :-)
> 
> > But see my comments below for a separate matter...
> > 
> > > ---
> > > Since v1.1:
> > > 
> > > - Change the description of the timestamp field; say that the type of
> > >   the timestamp is dependent on the flags field.
> > >  
> > >  Documentation/DocBook/media/v4l/compat.xml |   12 ++++++
> > >  Documentation/DocBook/media/v4l/io.xml     |   53 +++++++++++++++++----
> > >  Documentation/DocBook/media/v4l/v4l2.xml   |   12 ++++++-
> > >  include/uapi/linux/videodev2.h             |    4 ++
> > >  4 files changed, 69 insertions(+), 12 deletions(-)
> > > 
> > > diff --git a/Documentation/DocBook/media/v4l/compat.xml
> > > b/Documentation/DocBook/media/v4l/compat.xml index 4fdf6b5..651ca52
> > > 100644
> > > --- a/Documentation/DocBook/media/v4l/compat.xml
> > > +++ b/Documentation/DocBook/media/v4l/compat.xml
> > > @@ -2477,6 +2477,18 @@ that used it. It was originally scheduled for
> > > removal in 2.6.35.
> > >        </orderedlist>
> > >      </section>
> > > 
> > > +    <section>
> > > +      <title>V4L2 in Linux 3.8</title>
> > > +      <orderedlist>
> > > +        <listitem>
> > > +	  <para>Added timestamp types to
> > > +	  <structfield>flags</structfield> field in
> > > +	  <structname>v4l2_buffer</structname>. See <xref
> > > +	  linkend="buffer-flags" />.</para>
> > > +        </listitem>
> > > +      </orderedlist>
> > > +    </section>
> > > +
> > >      <section id="other">
> > >        <title>Relation of V4L2 to other Linux multimedia APIs</title>
> > > 
> > > diff --git a/Documentation/DocBook/media/v4l/io.xml
> > > b/Documentation/DocBook/media/v4l/io.xml index 7e2f3d7..1243fa1 100644
> > > --- a/Documentation/DocBook/media/v4l/io.xml
> > > +++ b/Documentation/DocBook/media/v4l/io.xml
> > > @@ -582,17 +582,19 @@ applications when an output stream.</entry>
> > >  	    <entry>struct timeval</entry>
> > >  	    <entry><structfield>timestamp</structfield></entry>
> > >  	    <entry></entry>
> > > -	    <entry><para>For input streams this is the
> > > -system time (as returned by the <function>gettimeofday()</function>
> > > -function) when the first data byte was captured. For output streams
> > > -the data will not be displayed before this time, secondary to the
> > > -nominal frame rate determined by the current video standard in
> > > -enqueued order. Applications can for example zero this field to
> > > -display frames as soon as possible. The driver stores the time at
> > > -which the first data byte was actually sent out in the
> > > -<structfield>timestamp</structfield> field. This permits
> > > -applications to monitor the drift between the video and system
> > > -clock.</para></entry>
> > > +	    <entry><para>For input streams this is time when the first data
> > > +	    byte was captured,
> > 
> > What should we do with this? In most drivers the timestamp is actually the
> > time that the *last* byte was captured. The reality is that the
> > application doesn't know whether it is the first or the last.
> > 
> > One option is to add a new flag for this, or to leave it open. The last
> > makes me uncomfortable, since there can be quite a difference between the
> > time of the first or last byte, and that definitely has an effect on the
> > A/V sync.
> 
> Very true. I'd also prefer to have this defined so the information would be
> available to the user space.
> 
> > This is a separate topic that should be handled in a separate patch, but I
> > do think we need to take a closer look at this.
> 
> I'm not against one more buffer flag to tell which one it is. :-)
> 
> There are hardly any other options than the frame start and frame end.
> 
> On the other hand, the FRAME_SYNC event is supported by some drivers and
> that can be used to obtain the timestamp from frame start. Not all drivers
> support it nor the applications can be expected to use this just to get a
> timestamp, though.
> 
> > > as returned by the
> > > +	    <function>clock_gettime()</function> function for the relevant
> > > +	    clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in
> > > +	    <xref linkend="buffer-flags" />. For output streams the data
> > > +	    will not be displayed before this time, secondary to the nominal
> > > +	    frame rate determined by the current video standard in enqueued
> > > +	    order. Applications can for example zero this field to display
> > > +	    frames as soon as possible.
> > 
> > There is not a single driver that supports this feature. There is also no
> > way an application can query the driver whether this feature is supported.
> > Personally I don't think this should be the task of a driver anyway: if
> > you want to postpone displaying a frame, then just wait before calling
> > QBUF. Don't add complicated logic in drivers/vb2 where it needs to hold
> > buffers back if the time hasn't been reached yet.
> 
> Assuming realtime clock, there could be some interesting interactions with
> this and daylight saving time or setting system clock, for example.
> 
> I'm definitely not against removing this, especially as no driver uses it.

Acked.

> > What might be much more interesting for output devices is if the timestamp
> > field is filled in with the expected display time on return of QBUF. That
> > would be very useful for regulating the flow of new frames.

Acked as well.

> > What do you think?
> 
> Fine for me. Sylwester also brought memory-to-memory devices (and
> memory-to-memory processing whether the device is classified as such in API
> or not) to my attention. For those devices it likely wouldn't matter at all
> what's the system time when the frame is processed since the frame wasn't
> captured at that time anyway.
> 
> In those cases it might makes sense to use timestamp that e.g. comes from
> the compressed stream, or pass encoder timestamps that are going to be part
> of the compressed stream. I think MPEG-related use cases were briefly
> mentioned in the timestamp discussion earlier.

When uncompressing a stream you will get the MPEG embedded timestamp on the 
capture side. The timestamp returned to userspace at QBUF time on the output 
side will still be unused. I don't really see a use case for returning the 
timestamp at which the frame is expected to be processed by the codec, so we 
could just make the field reserved for future use in that case.

> > > The driver stores the time at which
> > > +	    the first data byte was actually sent out in the
> > > +	    <structfield>timestamp</structfield> field.
> > 
> > Same problem as with the capture time: does the timestamp refer to the
> > first or last byte that's sent out? I think all output drivers set it to
> > the time of the last byte (== when the DMA of the frame is finished).
> 
> I haven't actually even seen a capture driver that would do otherwise, but
> that could be just me not knowing many enough. :-) Would we actually break
> something if we changed the definition to say that this is the timestamp
> taken when the frame is done?

For software timestamps we could do that, but for hardware timestamps the 
exact timestamping time may vary.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v1.2 1/4] v4l: Define video buffer flags for timestamp types

[Sakari Ailus]

Hi Laurent,

Thanks for the comments.

On Tue, Nov 27, 2012 at 05:04:29PM +0100, Laurent Pinchart wrote:
> On Thursday 22 November 2012 01:59:00 Sakari Ailus wrote:
> > On Wed, Nov 21, 2012 at 11:53:02PM +0100, Hans Verkuil wrote:
,,,
> > > What do you think?
> > 
> > Fine for me. Sylwester also brought memory-to-memory devices (and
> > memory-to-memory processing whether the device is classified as such in API
> > or not) to my attention. For those devices it likely wouldn't matter at all
> > what's the system time when the frame is processed since the frame wasn't
> > captured at that time anyway.
> > 
> > In those cases it might makes sense to use timestamp that e.g. comes from
> > the compressed stream, or pass encoder timestamps that are going to be part
> > of the compressed stream. I think MPEG-related use cases were briefly
> > mentioned in the timestamp discussion earlier.
> 
> When uncompressing a stream you will get the MPEG embedded timestamp on the 
> capture side. The timestamp returned to userspace at QBUF time on the output 
> side will still be unused. I don't really see a use case for returning the 
> timestamp at which the frame is expected to be processed by the codec, so we 
> could just make the field reserved for future use in that case.

Is the timestamp embedded in the compressed data itself in that case, or
where? Could this be codec-dependent?

> > > > The driver stores the time at which
> > > > +	    the first data byte was actually sent out in the
> > > > +	    <structfield>timestamp</structfield> field.
> > > 
> > > Same problem as with the capture time: does the timestamp refer to the
> > > first or last byte that's sent out? I think all output drivers set it to
> > > the time of the last byte (== when the DMA of the frame is finished).
> > 
> > I haven't actually even seen a capture driver that would do otherwise, but
> > that could be just me not knowing many enough. :-) Would we actually break
> > something if we changed the definition to say that this is the timestamp
> > taken when the frame is done?
> 
> For software timestamps we could do that, but for hardware timestamps the 
> exact timestamping time may vary.

Should we then do this for the timestamps that are obtained from the system
clock? We also haven't defined other kinds of tiemstamps yet.

For timestamp types that are hardware-dependent we could have exceptions.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

Re: [PATCH v1.2 1/4] v4l: Define video buffer flags for timestamp types

[Laurent Pinchart]

Hi Sakari,

On Sunday 02 December 2012 22:53:51 Sakari Ailus wrote:
> On Tue, Nov 27, 2012 at 05:04:29PM +0100, Laurent Pinchart wrote:
> > On Thursday 22 November 2012 01:59:00 Sakari Ailus wrote:
> > > On Wed, Nov 21, 2012 at 11:53:02PM +0100, Hans Verkuil wrote:
> ,,,
> 
> > > > What do you think?
> > > 
> > > Fine for me. Sylwester also brought memory-to-memory devices (and
> > > memory-to-memory processing whether the device is classified as such in
> > > API or not) to my attention. For those devices it likely wouldn't matter
> > > at all what's the system time when the frame is processed since the
> > > frame wasn't captured at that time anyway.
> > > 
> > > In those cases it might makes sense to use timestamp that e.g. comes
> > > from the compressed stream, or pass encoder timestamps that are going to
> > > be part of the compressed stream. I think MPEG-related use cases were
> > > briefly mentioned in the timestamp discussion earlier.
> > 
> > When uncompressing a stream you will get the MPEG embedded timestamp on
> > the capture side. The timestamp returned to userspace at QBUF time on the
> > output side will still be unused. I don't really see a use case for
> > returning the timestamp at which the frame is expected to be processed by
> > the codec, so we could just make the field reserved for future use in
> > that case.
> 
> Is the timestamp embedded in the compressed data itself in that case, or
> where?

Yes, it's embedded in the compressed stream.

> Could this be codec-dependent?

Of course, it would be too easy otherwise :-)

> > > > > The driver stores the time at which
> > > > > +	    the first data byte was actually sent out in the
> > > > > +	    <structfield>timestamp</structfield> field.
> > > > 
> > > > Same problem as with the capture time: does the timestamp refer to the
> > > > first or last byte that's sent out? I think all output drivers set it
> > > > to the time of the last byte (== when the DMA of the frame is
> > > > finished).
> > > 
> > > I haven't actually even seen a capture driver that would do otherwise,
> > > but that could be just me not knowing many enough. :-) Would we actually
> > > break something if we changed the definition to say that this is the
> > > timestamp taken when the frame is done?
> > 
> > For software timestamps we could do that, but for hardware timestamps the
> > exact timestamping time may vary.
> 
> Should we then do this for the timestamps that are obtained from the system
> clock? We also haven't defined other kinds of tiemstamps yet.

That sounds good to me.

> For timestamp types that are hardware-dependent we could have exceptions.

-- 
Regards,

Laurent Pinchart

[PATCH 2/4] v4l: Helper function for obtaining timestamps

[Sakari Ailus]

v4l2_get_timestamp() produces a monotonic timestamp but unlike
ktime_get_ts(), it uses struct timeval instead of struct timespec, saving
the drivers the conversion job when getting timestamps for v4l2_buffer's
timestamp field.

Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
---
 drivers/media/v4l2-core/v4l2-common.c |   10 ++++++++++
 include/media/v4l2-common.h           |    2 ++
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
index 380ddd8..614316f 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -978,3 +978,13 @@ const struct v4l2_frmsize_discrete *v4l2_find_nearest_format(
 	return best;
 }
 EXPORT_SYMBOL_GPL(v4l2_find_nearest_format);
+
+void v4l2_get_timestamp(struct timeval *tv)
+{
+	struct timespec ts;
+
+	ktime_get_ts(&ts);
+	tv->tv_sec = ts.tv_sec;
+	tv->tv_usec = ts.tv_nsec / NSEC_PER_USEC;
+}
+EXPORT_SYMBOL_GPL(v4l2_get_timestamp);
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index 1a0b2db..ec7c9c0 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -225,4 +225,6 @@ bool v4l2_detect_gtf(unsigned frame_height, unsigned hfreq, unsigned vsync,
 
 struct v4l2_fract v4l2_calc_aspect_ratio(u8 hor_landscape, u8 vert_portrait);
 
+void v4l2_get_timestamp(struct timeval *tv);
+
 #endif /* V4L2_COMMON_H_ */
-- 
1.7.2.5

Re: [PATCH 2/4] v4l: Helper function for obtaining timestamps

[Hans Verkuil]

On Thu November 15 2012 23:06:45 Sakari Ailus wrote:
> v4l2_get_timestamp() produces a monotonic timestamp but unlike
> ktime_get_ts(), it uses struct timeval instead of struct timespec, saving
> the drivers the conversion job when getting timestamps for v4l2_buffer's
> timestamp field.
> 
> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
> ---
>  drivers/media/v4l2-core/v4l2-common.c |   10 ++++++++++
>  include/media/v4l2-common.h           |    2 ++
>  2 files changed, 12 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
> index 380ddd8..614316f 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -978,3 +978,13 @@ const struct v4l2_frmsize_discrete *v4l2_find_nearest_format(
>  	return best;
>  }
>  EXPORT_SYMBOL_GPL(v4l2_find_nearest_format);
> +
> +void v4l2_get_timestamp(struct timeval *tv)
> +{
> +	struct timespec ts;
> +
> +	ktime_get_ts(&ts);
> +	tv->tv_sec = ts.tv_sec;
> +	tv->tv_usec = ts.tv_nsec / NSEC_PER_USEC;
> +}
> +EXPORT_SYMBOL_GPL(v4l2_get_timestamp);
> diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
> index 1a0b2db..ec7c9c0 100644
> --- a/include/media/v4l2-common.h
> +++ b/include/media/v4l2-common.h
> @@ -225,4 +225,6 @@ bool v4l2_detect_gtf(unsigned frame_height, unsigned hfreq, unsigned vsync,
>  
>  struct v4l2_fract v4l2_calc_aspect_ratio(u8 hor_landscape, u8 vert_portrait);
>  
> +void v4l2_get_timestamp(struct timeval *tv);
> +
>  #endif /* V4L2_COMMON_H_ */
> 

Acked-by: Hans Verkuil <hans.verkuil@cisco.com>

Regards,

	Hans

[PATCH 3/4] v4l: Convert drivers to use monotonic timestamps

[Sakari Ailus]

Convert drivers using wall clock time (CLOCK_REALTIME) to timestamp from the
monotonic timer (CLOCK_MONOTONIC).

Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
---
 drivers/media/common/saa7146/saa7146_fops.c        |    2 +-
 drivers/media/pci/bt8xx/bttv-driver.c              |    6 +++---
 drivers/media/pci/cx23885/cx23885-core.c           |    2 +-
 drivers/media/pci/cx23885/cx23885-video.c          |    2 +-
 drivers/media/pci/cx25821/cx25821-video.c          |    2 +-
 drivers/media/pci/cx88/cx88-core.c                 |    2 +-
 drivers/media/pci/meye/meye.c                      |    4 ++--
 drivers/media/pci/saa7134/saa7134-core.c           |    2 +-
 drivers/media/pci/sta2x11/sta2x11_vip.c            |    2 +-
 drivers/media/pci/zoran/zoran_device.c             |    4 ++--
 drivers/media/platform/blackfin/bfin_capture.c     |    4 +---
 drivers/media/platform/davinci/vpfe_capture.c      |    5 +----
 drivers/media/platform/davinci/vpif_capture.c      |    2 +-
 drivers/media/platform/davinci/vpif_display.c      |    6 +++---
 drivers/media/platform/fsl-viu.c                   |    2 +-
 drivers/media/platform/omap/omap_vout.c            |    2 +-
 drivers/media/platform/omap24xxcam.c               |    2 +-
 drivers/media/platform/sh_vou.c                    |    2 +-
 drivers/media/platform/soc_camera/atmel-isi.c      |    2 +-
 drivers/media/platform/soc_camera/mx1_camera.c     |    2 +-
 drivers/media/platform/soc_camera/mx2_camera.c     |    4 ++--
 drivers/media/platform/soc_camera/mx3_camera.c     |    2 +-
 drivers/media/platform/soc_camera/omap1_camera.c   |    2 +-
 drivers/media/platform/soc_camera/pxa_camera.c     |    2 +-
 .../platform/soc_camera/sh_mobile_ceu_camera.c     |    2 +-
 drivers/media/platform/timblogiw.c                 |    2 +-
 drivers/media/platform/vino.c                      |    8 ++++----
 drivers/media/platform/vivi.c                      |    6 ++----
 drivers/media/usb/au0828/au0828-video.c            |    4 ++--
 drivers/media/usb/cpia2/cpia2_usb.c                |    2 +-
 drivers/media/usb/cx231xx/cx231xx-417.c            |    4 ++--
 drivers/media/usb/cx231xx/cx231xx-vbi.c            |    2 +-
 drivers/media/usb/cx231xx/cx231xx-video.c          |    2 +-
 drivers/media/usb/em28xx/em28xx-video.c            |    4 ++--
 drivers/media/usb/pwc/pwc-if.c                     |    3 ++-
 drivers/media/usb/s2255/s2255drv.c                 |    6 ++----
 drivers/media/usb/sn9c102/sn9c102_core.c           |    3 ++-
 drivers/media/usb/stk1160/stk1160-video.c          |    2 +-
 drivers/media/usb/stkwebcam/stk-webcam.c           |    2 +-
 drivers/media/usb/tlg2300/pd-video.c               |    2 +-
 drivers/media/usb/tm6000/tm6000-video.c            |    2 +-
 drivers/media/usb/usbvision/usbvision-core.c       |    2 +-
 drivers/media/usb/zr364xx/zr364xx.c                |    6 ++----
 43 files changed, 61 insertions(+), 70 deletions(-)

diff --git a/drivers/media/common/saa7146/saa7146_fops.c b/drivers/media/common/saa7146/saa7146_fops.c
index b3890bd..2652f91 100644
--- a/drivers/media/common/saa7146/saa7146_fops.c
+++ b/drivers/media/common/saa7146/saa7146_fops.c
@@ -105,7 +105,7 @@ void saa7146_buffer_finish(struct saa7146_dev *dev,
 	}
 
 	q->curr->vb.state = state;
-	do_gettimeofday(&q->curr->vb.ts);
+	v4l2_get_timestamp(&q->curr->vb.ts);
 	wake_up(&q->curr->vb.done);
 
 	q->curr = NULL;
diff --git a/drivers/media/pci/bt8xx/bttv-driver.c b/drivers/media/pci/bt8xx/bttv-driver.c
index de6f41f..346458b 100644
--- a/drivers/media/pci/bt8xx/bttv-driver.c
+++ b/drivers/media/pci/bt8xx/bttv-driver.c
@@ -3835,7 +3835,7 @@ bttv_irq_wakeup_video(struct bttv *btv, struct bttv_buffer_set *wakeup,
 {
 	struct timeval ts;
 
-	do_gettimeofday(&ts);
+	v4l2_get_timestamp(&ts);
 
 	if (wakeup->top == wakeup->bottom) {
 		if (NULL != wakeup->top && curr->top != wakeup->top) {
@@ -3878,7 +3878,7 @@ bttv_irq_wakeup_vbi(struct bttv *btv, struct bttv_buffer *wakeup,
 	if (NULL == wakeup)
 		return;
 
-	do_gettimeofday(&ts);
+	v4l2_get_timestamp(&ts);
 	wakeup->vb.ts = ts;
 	wakeup->vb.field_count = btv->field_count;
 	wakeup->vb.state = state;
@@ -3949,7 +3949,7 @@ bttv_irq_wakeup_top(struct bttv *btv)
 	btv->curr.top = NULL;
 	bttv_risc_hook(btv, RISC_SLOT_O_FIELD, NULL, 0);
 
-	do_gettimeofday(&wakeup->vb.ts);
+	v4l2_get_timestamp(&wakeup->vb.ts);
 	wakeup->vb.field_count = btv->field_count;
 	wakeup->vb.state = VIDEOBUF_DONE;
 	wake_up(&wakeup->vb.done);
diff --git a/drivers/media/pci/cx23885/cx23885-core.c b/drivers/media/pci/cx23885/cx23885-core.c
index 065ecd5..c757259 100644
--- a/drivers/media/pci/cx23885/cx23885-core.c
+++ b/drivers/media/pci/cx23885/cx23885-core.c
@@ -439,7 +439,7 @@ void cx23885_wakeup(struct cx23885_tsport *port,
 		if ((s16) (count - buf->count) < 0)
 			break;
 
-		do_gettimeofday(&buf->vb.ts);
+		v4l2_get_timestamp(&buf->vb.ts);
 		dprintk(2, "[%p/%d] wakeup reg=%d buf=%d\n", buf, buf->vb.i,
 			count, buf->count);
 		buf->vb.state = VIDEOBUF_DONE;
diff --git a/drivers/media/pci/cx23885/cx23885-video.c b/drivers/media/pci/cx23885/cx23885-video.c
index 1a21926..8397531 100644
--- a/drivers/media/pci/cx23885/cx23885-video.c
+++ b/drivers/media/pci/cx23885/cx23885-video.c
@@ -300,7 +300,7 @@ void cx23885_video_wakeup(struct cx23885_dev *dev,
 		if ((s16) (count - buf->count) < 0)
 			break;
 
-		do_gettimeofday(&buf->vb.ts);
+		v4l2_get_timestamp(&buf->vb.ts);
 		dprintk(2, "[%p/%d] wakeup reg=%d buf=%d\n", buf, buf->vb.i,
 			count, buf->count);
 		buf->vb.state = VIDEOBUF_DONE;
diff --git a/drivers/media/pci/cx25821/cx25821-video.c b/drivers/media/pci/cx25821/cx25821-video.c
index 53b16dd..d4de021 100644
--- a/drivers/media/pci/cx25821/cx25821-video.c
+++ b/drivers/media/pci/cx25821/cx25821-video.c
@@ -130,7 +130,7 @@ void cx25821_video_wakeup(struct cx25821_dev *dev, struct cx25821_dmaqueue *q,
 		if ((s16) (count - buf->count) < 0)
 			break;
 
-		do_gettimeofday(&buf->vb.ts);
+		v4l2_get_timestamp(&buf->vb.ts);
 		buf->vb.state = VIDEOBUF_DONE;
 		list_del(&buf->vb.queue);
 		wake_up(&buf->vb.done);
diff --git a/drivers/media/pci/cx88/cx88-core.c b/drivers/media/pci/cx88/cx88-core.c
index 19a5875..39f095c 100644
--- a/drivers/media/pci/cx88/cx88-core.c
+++ b/drivers/media/pci/cx88/cx88-core.c
@@ -549,7 +549,7 @@ void cx88_wakeup(struct cx88_core *core,
 		 * up to 32767 buffers in flight... */
 		if ((s16) (count - buf->count) < 0)
 			break;
-		do_gettimeofday(&buf->vb.ts);
+		v4l2_get_timestamp(&buf->vb.ts);
 		dprintk(2,"[%p/%d] wakeup reg=%d buf=%d\n",buf,buf->vb.i,
 			count, buf->count);
 		buf->vb.state = VIDEOBUF_DONE;
diff --git a/drivers/media/pci/meye/meye.c b/drivers/media/pci/meye/meye.c
index ae7d320..288adea 100644
--- a/drivers/media/pci/meye/meye.c
+++ b/drivers/media/pci/meye/meye.c
@@ -811,7 +811,7 @@ again:
 				      mchip_hsize() * mchip_vsize() * 2);
 		meye.grab_buffer[reqnr].size = mchip_hsize() * mchip_vsize() * 2;
 		meye.grab_buffer[reqnr].state = MEYE_BUF_DONE;
-		do_gettimeofday(&meye.grab_buffer[reqnr].timestamp);
+		v4l2_get_timestamp(&meye.grab_buffer[reqnr].timestamp);
 		meye.grab_buffer[reqnr].sequence = sequence++;
 		kfifo_in_locked(&meye.doneq, (unsigned char *)&reqnr,
 				sizeof(int), &meye.doneq_lock);
@@ -832,7 +832,7 @@ again:
 		       size);
 		meye.grab_buffer[reqnr].size = size;
 		meye.grab_buffer[reqnr].state = MEYE_BUF_DONE;
-		do_gettimeofday(&meye.grab_buffer[reqnr].timestamp);
+		v4l2_get_timestamp(&meye.grab_buffer[reqnr].timestamp);
 		meye.grab_buffer[reqnr].sequence = sequence++;
 		kfifo_in_locked(&meye.doneq, (unsigned char *)&reqnr,
 				sizeof(int), &meye.doneq_lock);
diff --git a/drivers/media/pci/saa7134/saa7134-core.c b/drivers/media/pci/saa7134/saa7134-core.c
index 8976d0e..e1aeb51 100644
--- a/drivers/media/pci/saa7134/saa7134-core.c
+++ b/drivers/media/pci/saa7134/saa7134-core.c
@@ -308,7 +308,7 @@ void saa7134_buffer_finish(struct saa7134_dev *dev,
 
 	/* finish current buffer */
 	q->curr->vb.state = state;
-	do_gettimeofday(&q->curr->vb.ts);
+	v4l2_get_timestamp(&q->curr->vb.ts);
 	wake_up(&q->curr->vb.done);
 	q->curr = NULL;
 }
diff --git a/drivers/media/pci/sta2x11/sta2x11_vip.c b/drivers/media/pci/sta2x11/sta2x11_vip.c
index 4c10205..ed1337a 100644
--- a/drivers/media/pci/sta2x11/sta2x11_vip.c
+++ b/drivers/media/pci/sta2x11/sta2x11_vip.c
@@ -1088,7 +1088,7 @@ static irqreturn_t vip_irq(int irq, struct sta2x11_vip *vip)
 
 	REG_WRITE(vip, DVP_CTL, REG_READ(vip, DVP_CTL) & ~DVP_CTL_ENA);
 	if (vip->active) {
-		do_gettimeofday(&vip->active->ts);
+		v4l2_get_timestamp(&vip->active->ts);
 		vip->active->field_count++;
 		vip->active->state = VIDEOBUF_DONE;
 		wake_up(&vip->active->done);
diff --git a/drivers/media/pci/zoran/zoran_device.c b/drivers/media/pci/zoran/zoran_device.c
index a4cd504..519164c 100644
--- a/drivers/media/pci/zoran/zoran_device.c
+++ b/drivers/media/pci/zoran/zoran_device.c
@@ -1169,7 +1169,7 @@ zoran_reap_stat_com (struct zoran *zr)
 		}
 		frame = zr->jpg_pend[zr->jpg_dma_tail & BUZ_MASK_FRAME];
 		buffer = &zr->jpg_buffers.buffer[frame];
-		do_gettimeofday(&buffer->bs.timestamp);
+		v4l2_get_timestamp(&buffer->bs.timestamp);
 
 		if (zr->codec_mode == BUZ_MODE_MOTION_COMPRESS) {
 			buffer->bs.length = (stat_com & 0x7fffff) >> 1;
@@ -1407,7 +1407,7 @@ zoran_irq (int             irq,
 
 						zr->v4l_buffers.buffer[zr->v4l_grab_frame].state = BUZ_STATE_DONE;
 						zr->v4l_buffers.buffer[zr->v4l_grab_frame].bs.seq = zr->v4l_grab_seq;
-						do_gettimeofday(&zr->v4l_buffers.buffer[zr->v4l_grab_frame].bs.timestamp);
+						v4l2_get_timestamp(&zr->v4l_buffers.buffer[zr->v4l_grab_frame].bs.timestamp);
 						zr->v4l_grab_frame = NO_GRAB_ACTIVE;
 						zr->v4l_pend_tail++;
 					}
diff --git a/drivers/media/platform/blackfin/bfin_capture.c b/drivers/media/platform/blackfin/bfin_capture.c
index ec476ef..d422d3c 100644
--- a/drivers/media/platform/blackfin/bfin_capture.c
+++ b/drivers/media/platform/blackfin/bfin_capture.c
@@ -484,15 +484,13 @@ static irqreturn_t bcap_isr(int irq, void *dev_id)
 {
 	struct ppi_if *ppi = dev_id;
 	struct bcap_device *bcap_dev = ppi->priv;
-	struct timeval timevalue;
 	struct vb2_buffer *vb = &bcap_dev->cur_frm->vb;
 	dma_addr_t addr;
 
 	spin_lock(&bcap_dev->lock);
 
 	if (bcap_dev->cur_frm != bcap_dev->next_frm) {
-		do_gettimeofday(&timevalue);
-		vb->v4l2_buf.timestamp = timevalue;
+		v4l2_get_timestamp(&vb->v4l2_buf.timestamp);
 		vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
 		bcap_dev->cur_frm = bcap_dev->next_frm;
 	}
diff --git a/drivers/media/platform/davinci/vpfe_capture.c b/drivers/media/platform/davinci/vpfe_capture.c
index 8be492c..65f4264 100644
--- a/drivers/media/platform/davinci/vpfe_capture.c
+++ b/drivers/media/platform/davinci/vpfe_capture.c
@@ -560,10 +560,7 @@ static void vpfe_schedule_bottom_field(struct vpfe_device *vpfe_dev)
 
 static void vpfe_process_buffer_complete(struct vpfe_device *vpfe_dev)
 {
-	struct timeval timevalue;
-
-	do_gettimeofday(&timevalue);
-	vpfe_dev->cur_frm->ts = timevalue;
+	v4l2_get_timestamp(&vpfe_dev->cur_frm->ts);
 	vpfe_dev->cur_frm->state = VIDEOBUF_DONE;
 	vpfe_dev->cur_frm->size = vpfe_dev->fmt.fmt.pix.sizeimage;
 	wake_up_interruptible(&vpfe_dev->cur_frm->done);
diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c
index fcabc02..1f12640 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -401,7 +401,7 @@ static struct vb2_ops video_qops = {
  */
 static void vpif_process_buffer_complete(struct common_obj *common)
 {
-	do_gettimeofday(&common->cur_frm->vb.v4l2_buf.timestamp);
+	v4l2_get_timestamp(&common->cur_frm->vb.v4l2_buf.timestamp);
 	vb2_buffer_done(&common->cur_frm->vb,
 					    VB2_BUF_STATE_DONE);
 	/* Make curFrm pointing to nextFrm */
diff --git a/drivers/media/platform/davinci/vpif_display.c b/drivers/media/platform/davinci/vpif_display.c
index b716fbd..2bc6eef 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -390,7 +390,7 @@ static void process_interlaced_mode(int fid, struct common_obj *common)
 		/* one frame is displayed If next frame is
 		 *  available, release cur_frm and move on */
 		/* Copy frame display time */
-		do_gettimeofday(&common->cur_frm->vb.v4l2_buf.timestamp);
+		v4l2_get_timestamp(&common->cur_frm->vb.v4l2_buf.timestamp);
 		/* Change status of the cur_frm */
 		vb2_buffer_done(&common->cur_frm->vb,
 					    VB2_BUF_STATE_DONE);
@@ -444,8 +444,8 @@ static irqreturn_t vpif_channel_isr(int irq, void *dev_id)
 			if (!channel_first_int[i][channel_id]) {
 				/* Mark status of the cur_frm to
 				 * done and unlock semaphore on it */
-				do_gettimeofday(&common->cur_frm->vb.
-						v4l2_buf.timestamp);
+				v4l2_get_timestamp(&common->cur_frm->vb.
+						   v4l2_buf.timestamp);
 				vb2_buffer_done(&common->cur_frm->vb,
 					    VB2_BUF_STATE_DONE);
 				/* Make cur_frm pointing to next_frm */
diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c
index a8ddb0c..d464509 100644
--- a/drivers/media/platform/fsl-viu.c
+++ b/drivers/media/platform/fsl-viu.c
@@ -1181,7 +1181,7 @@ static void viu_capture_intr(struct viu_dev *dev, u32 status)
 
 		if (waitqueue_active(&buf->vb.done)) {
 			list_del(&buf->vb.queue);
-			do_gettimeofday(&buf->vb.ts);
+			v4l2_get_timestamp(&buf->vb.ts);
 			buf->vb.state = VIDEOBUF_DONE;
 			buf->vb.field_count++;
 			wake_up(&buf->vb.done);
diff --git a/drivers/media/platform/omap/omap_vout.c b/drivers/media/platform/omap/omap_vout.c
index 837cb6d..e4f76ac 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -597,7 +597,7 @@ static void omap_vout_isr(void *arg, unsigned int irqstatus)
 		return;
 
 	spin_lock(&vout->vbq_lock);
-	do_gettimeofday(&timevalue);
+	v4l2_get_timestamp(&timevalue);
 
 	switch (cur_display->type) {
 	case OMAP_DISPLAY_TYPE_DSI:
diff --git a/drivers/media/platform/omap24xxcam.c b/drivers/media/platform/omap24xxcam.c
index 70f45c3..eda3274 100644
--- a/drivers/media/platform/omap24xxcam.c
+++ b/drivers/media/platform/omap24xxcam.c
@@ -402,7 +402,7 @@ static void omap24xxcam_vbq_complete(struct omap24xxcam_sgdma *sgdma,
 		omap24xxcam_core_disable(cam);
 	spin_unlock_irqrestore(&cam->core_enable_disable_lock, flags);
 
-	do_gettimeofday(&vb->ts);
+	v4l2_get_timestamp(&vb->ts);
 	vb->field_count = atomic_add_return(2, &fh->field_count);
 	if (csr & csr_error) {
 		vb->state = VIDEOBUF_ERROR;
diff --git a/drivers/media/platform/sh_vou.c b/drivers/media/platform/sh_vou.c
index 85fd312..520740b 100644
--- a/drivers/media/platform/sh_vou.c
+++ b/drivers/media/platform/sh_vou.c
@@ -1090,7 +1090,7 @@ static irqreturn_t sh_vou_isr(int irq, void *dev_id)
 	list_del(&vb->queue);
 
 	vb->state = VIDEOBUF_DONE;
-	do_gettimeofday(&vb->ts);
+	v4l2_get_timestamp(&vb->ts);
 	vb->field_count++;
 	wake_up(&vb->done);
 
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c b/drivers/media/platform/soc_camera/atmel-isi.c
index 6274a91..c8d748a 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -166,7 +166,7 @@ static irqreturn_t atmel_isi_handle_streaming(struct atmel_isi *isi)
 		struct frame_buffer *buf = isi->active;
 
 		list_del_init(&buf->list);
-		do_gettimeofday(&vb->v4l2_buf.timestamp);
+		v4l2_get_timestamp(&vb->v4l2_buf.timestamp);
 		vb->v4l2_buf.sequence = isi->sequence++;
 		vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
 	}
diff --git a/drivers/media/platform/soc_camera/mx1_camera.c b/drivers/media/platform/soc_camera/mx1_camera.c
index bbe7099..8e33ca1 100644
--- a/drivers/media/platform/soc_camera/mx1_camera.c
+++ b/drivers/media/platform/soc_camera/mx1_camera.c
@@ -307,7 +307,7 @@ static void mx1_camera_wakeup(struct mx1_camera_dev *pcdev,
 	/* _init is used to debug races, see comment in mx1_camera_reqbufs() */
 	list_del_init(&vb->queue);
 	vb->state = VIDEOBUF_DONE;
-	do_gettimeofday(&vb->ts);
+	v4l2_get_timestamp(&vb->ts);
 	vb->field_count++;
 	wake_up(&vb->done);
 
diff --git a/drivers/media/platform/soc_camera/mx2_camera.c b/drivers/media/platform/soc_camera/mx2_camera.c
index 9fd9d1c..e474a38 100644
--- a/drivers/media/platform/soc_camera/mx2_camera.c
+++ b/drivers/media/platform/soc_camera/mx2_camera.c
@@ -516,7 +516,7 @@ static void mx25_camera_frame_done(struct mx2_camera_dev *pcdev, int fb,
 	dev_dbg(pcdev->dev, "%s (vb=0x%p) 0x%p %lu\n", __func__,
 		vb, vb2_plane_vaddr(vb, 0), vb2_get_plane_payload(vb, 0));
 
-	do_gettimeofday(&vb->v4l2_buf.timestamp);
+	v4l2_get_timestamp(&vb->v4l2_buf.timestamp);
 	vb->v4l2_buf.sequence++;
 	vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
 
@@ -1552,7 +1552,7 @@ static void mx27_camera_frame_done_emma(struct mx2_camera_dev *pcdev,
 				vb2_get_plane_payload(vb, 0));
 
 		list_del_init(&buf->internal.queue);
-		do_gettimeofday(&vb->v4l2_buf.timestamp);
+		v4l2_get_timestamp(&vb->v4l2_buf.timestamp);
 		vb->v4l2_buf.sequence = pcdev->frame_count;
 		if (err)
 			vb2_buffer_done(vb, VB2_BUF_STATE_ERROR);
diff --git a/drivers/media/platform/soc_camera/mx3_camera.c b/drivers/media/platform/soc_camera/mx3_camera.c
index 3557ac9..dea1ad0 100644
--- a/drivers/media/platform/soc_camera/mx3_camera.c
+++ b/drivers/media/platform/soc_camera/mx3_camera.c
@@ -156,7 +156,7 @@ static void mx3_cam_dma_done(void *arg)
 		struct mx3_camera_buffer *buf = to_mx3_vb(vb);
 
 		list_del_init(&buf->queue);
-		do_gettimeofday(&vb->v4l2_buf.timestamp);
+		v4l2_get_timestamp(&vb->v4l2_buf.timestamp);
 		vb->v4l2_buf.field = mx3_cam->field;
 		vb->v4l2_buf.sequence = mx3_cam->sequence++;
 		vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
diff --git a/drivers/media/platform/soc_camera/omap1_camera.c b/drivers/media/platform/soc_camera/omap1_camera.c
index fa08c76..f4aaaeb 100644
--- a/drivers/media/platform/soc_camera/omap1_camera.c
+++ b/drivers/media/platform/soc_camera/omap1_camera.c
@@ -591,7 +591,7 @@ static void videobuf_done(struct omap1_cam_dev *pcdev,
 			suspend_capture(pcdev);
 		}
 		vb->state = result;
-		do_gettimeofday(&vb->ts);
+		v4l2_get_timestamp(&vb->ts);
 		if (result != VIDEOBUF_ERROR)
 			vb->field_count++;
 		wake_up(&vb->done);
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c b/drivers/media/platform/soc_camera/pxa_camera.c
index 1e3776d..108e2d2 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -681,7 +681,7 @@ static void pxa_camera_wakeup(struct pxa_camera_dev *pcdev,
 	/* _init is used to debug races, see comment in pxa_camera_reqbufs() */
 	list_del_init(&vb->queue);
 	vb->state = VIDEOBUF_DONE;
-	do_gettimeofday(&vb->ts);
+	v4l2_get_timestamp(&vb->ts);
 	vb->field_count++;
 	wake_up(&vb->done);
 	dev_dbg(pcdev->soc_host.v4l2_dev.dev, "%s dequeud buffer (vb=0x%p)\n",
diff --git a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c b/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
index 0a24253..1786338 100644
--- a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
+++ b/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
@@ -516,7 +516,7 @@ static irqreturn_t sh_mobile_ceu_irq(int irq, void *data)
 		pcdev->active = NULL;
 
 	ret = sh_mobile_ceu_capture(pcdev);
-	do_gettimeofday(&vb->v4l2_buf.timestamp);
+	v4l2_get_timestamp(&vb->v4l2_buf.timestamp);
 	if (!ret) {
 		vb->v4l2_buf.field = pcdev->field;
 		vb->v4l2_buf.sequence = pcdev->sequence++;
diff --git a/drivers/media/platform/timblogiw.c b/drivers/media/platform/timblogiw.c
index 02194c0..9de0141 100644
--- a/drivers/media/platform/timblogiw.c
+++ b/drivers/media/platform/timblogiw.c
@@ -130,7 +130,7 @@ static void timblogiw_dma_cb(void *data)
 
 	if (vb->state != VIDEOBUF_ERROR) {
 		list_del(&vb->queue);
-		do_gettimeofday(&vb->ts);
+		v4l2_get_timestamp(&vb->ts);
 		vb->field_count = fh->frame_count * 2;
 		vb->state = VIDEOBUF_DONE;
 
diff --git a/drivers/media/platform/vino.c b/drivers/media/platform/vino.c
index 70b0bf4..28350e7 100644
--- a/drivers/media/platform/vino.c
+++ b/drivers/media/platform/vino.c
@@ -2474,8 +2474,8 @@ static irqreturn_t vino_interrupt(int irq, void *dev_id)
 
 		if ((!handled_a) && (done_a || skip_a)) {
 			if (!skip_a) {
-				do_gettimeofday(&vino_drvdata->
-						a.int_data.timestamp);
+				v4l2_get_timestamp(
+					&vino_drvdata->a.int_data.timestamp);
 				vino_drvdata->a.int_data.frame_counter = fc_a;
 			}
 			vino_drvdata->a.int_data.skip = skip_a;
@@ -2489,8 +2489,8 @@ static irqreturn_t vino_interrupt(int irq, void *dev_id)
 
 		if ((!handled_b) && (done_b || skip_b)) {
 			if (!skip_b) {
-				do_gettimeofday(&vino_drvdata->
-						b.int_data.timestamp);
+				v4l2_get_timestamp(
+					&vino_drvdata->b.int_data.timestamp);
 				vino_drvdata->b.int_data.frame_counter = fc_b;
 			}
 			vino_drvdata->b.int_data.skip = skip_b;
diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
index 3e6902a..3c2225f 100644
--- a/drivers/media/platform/vivi.c
+++ b/drivers/media/platform/vivi.c
@@ -559,7 +559,6 @@ static void vivi_fillbuff(struct vivi_dev *dev, struct vivi_buffer *buf)
 {
 	int wmax = dev->width;
 	int hmax = dev->height;
-	struct timeval ts;
 	void *vbuf = vb2_plane_vaddr(&buf->vb, 0);
 	unsigned ms;
 	char str[100];
@@ -627,8 +626,7 @@ static void vivi_fillbuff(struct vivi_dev *dev, struct vivi_buffer *buf)
 	buf->vb.v4l2_buf.field = V4L2_FIELD_INTERLACED;
 	dev->field_count++;
 	buf->vb.v4l2_buf.sequence = dev->field_count >> 1;
-	do_gettimeofday(&ts);
-	buf->vb.v4l2_buf.timestamp = ts;
+	v4l2_get_timestamp(&buf->vb.v4l2_buf.timestamp);
 }
 
 static void vivi_thread_tick(struct vivi_dev *dev)
@@ -650,7 +648,7 @@ static void vivi_thread_tick(struct vivi_dev *dev)
 	list_del(&buf->list);
 	spin_unlock_irqrestore(&dev->slock, flags);
 
-	do_gettimeofday(&buf->vb.v4l2_buf.timestamp);
+	v4l2_get_timestamp(&buf->vb.v4l2_buf.timestamp);
 
 	/* Fill buffer */
 	vivi_fillbuff(dev, buf);
diff --git a/drivers/media/usb/au0828/au0828-video.c b/drivers/media/usb/au0828/au0828-video.c
index 45387aa..8b9e826 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -304,7 +304,7 @@ static inline void buffer_filled(struct au0828_dev *dev,
 
 	buf->vb.state = VIDEOBUF_DONE;
 	buf->vb.field_count++;
-	do_gettimeofday(&buf->vb.ts);
+	v4l2_get_timestamp(&buf->vb.ts);
 
 	dev->isoc_ctl.buf = NULL;
 
@@ -321,7 +321,7 @@ static inline void vbi_buffer_filled(struct au0828_dev *dev,
 
 	buf->vb.state = VIDEOBUF_DONE;
 	buf->vb.field_count++;
-	do_gettimeofday(&buf->vb.ts);
+	v4l2_get_timestamp(&buf->vb.ts);
 
 	dev->isoc_ctl.vbi_buf = NULL;
 
diff --git a/drivers/media/usb/cpia2/cpia2_usb.c b/drivers/media/usb/cpia2/cpia2_usb.c
index 95b5d6e..be17192 100644
--- a/drivers/media/usb/cpia2/cpia2_usb.c
+++ b/drivers/media/usb/cpia2/cpia2_usb.c
@@ -328,7 +328,7 @@ static void cpia2_usb_complete(struct urb *urb)
 				continue;
 			}
 			DBG("Start of frame pattern found\n");
-			do_gettimeofday(&cam->workbuff->timestamp);
+			v4l2_get_timestamp(&cam->workbuff->timestamp);
 			cam->workbuff->seq = cam->frame_count++;
 			cam->workbuff->data[0] = 0xFF;
 			cam->workbuff->data[1] = 0xD8;
diff --git a/drivers/media/usb/cx231xx/cx231xx-417.c b/drivers/media/usb/cx231xx/cx231xx-417.c
index b024e51..28688db 100644
--- a/drivers/media/usb/cx231xx/cx231xx-417.c
+++ b/drivers/media/usb/cx231xx/cx231xx-417.c
@@ -1291,7 +1291,7 @@ static void buffer_copy(struct cx231xx *dev, char *data, int len, struct urb *ur
 
 			buf->vb.state = VIDEOBUF_DONE;
 			buf->vb.field_count++;
-			do_gettimeofday(&buf->vb.ts);
+			v4l2_get_timestamp(&buf->vb.ts);
 			list_del(&buf->vb.queue);
 			wake_up(&buf->vb.done);
 			dma_q->mpeg_buffer_completed = 0;
@@ -1327,7 +1327,7 @@ static void buffer_filled(char *data, int len, struct urb *urb,
 		memcpy(vbuf, data, len);
 		buf->vb.state = VIDEOBUF_DONE;
 		buf->vb.field_count++;
-		do_gettimeofday(&buf->vb.ts);
+		v4l2_get_timestamp(&buf->vb.ts);
 		list_del(&buf->vb.queue);
 		wake_up(&buf->vb.done);
 
diff --git a/drivers/media/usb/cx231xx/cx231xx-vbi.c b/drivers/media/usb/cx231xx/cx231xx-vbi.c
index ac7db52..46e3892 100644
--- a/drivers/media/usb/cx231xx/cx231xx-vbi.c
+++ b/drivers/media/usb/cx231xx/cx231xx-vbi.c
@@ -530,7 +530,7 @@ static inline void vbi_buffer_filled(struct cx231xx *dev,
 
 	buf->vb.state = VIDEOBUF_DONE;
 	buf->vb.field_count++;
-	do_gettimeofday(&buf->vb.ts);
+	v4l2_get_timestamp(&buf->vb.ts);
 
 	dev->vbi_mode.bulk_ctl.buf = NULL;
 
diff --git a/drivers/media/usb/cx231xx/cx231xx-video.c b/drivers/media/usb/cx231xx/cx231xx-video.c
index fedf785..239cb91 100644
--- a/drivers/media/usb/cx231xx/cx231xx-video.c
+++ b/drivers/media/usb/cx231xx/cx231xx-video.c
@@ -235,7 +235,7 @@ static inline void buffer_filled(struct cx231xx *dev,
 	cx231xx_isocdbg("[%p/%d] wakeup\n", buf, buf->vb.i);
 	buf->vb.state = VIDEOBUF_DONE;
 	buf->vb.field_count++;
-	do_gettimeofday(&buf->vb.ts);
+	v4l2_get_timestamp(&buf->vb.ts);
 
 	if (dev->USE_ISO)
 		dev->video_mode.isoc_ctl.buf = NULL;
diff --git a/drivers/media/usb/em28xx/em28xx-video.c b/drivers/media/usb/em28xx/em28xx-video.c
index 1e553d3..766ad12 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -163,7 +163,7 @@ static inline void buffer_filled(struct em28xx *dev,
 	em28xx_isocdbg("[%p/%d] wakeup\n", buf, buf->vb.i);
 	buf->vb.state = VIDEOBUF_DONE;
 	buf->vb.field_count++;
-	do_gettimeofday(&buf->vb.ts);
+	v4l2_get_timestamp(&buf->vb.ts);
 
 	dev->isoc_ctl.vid_buf = NULL;
 
@@ -180,7 +180,7 @@ static inline void vbi_buffer_filled(struct em28xx *dev,
 
 	buf->vb.state = VIDEOBUF_DONE;
 	buf->vb.field_count++;
-	do_gettimeofday(&buf->vb.ts);
+	v4l2_get_timestamp(&buf->vb.ts);
 
 	dev->isoc_ctl.vbi_buf = NULL;
 
diff --git a/drivers/media/usb/pwc/pwc-if.c b/drivers/media/usb/pwc/pwc-if.c
index 5210239..21c1523 100644
--- a/drivers/media/usb/pwc/pwc-if.c
+++ b/drivers/media/usb/pwc/pwc-if.c
@@ -316,7 +316,8 @@ static void pwc_isoc_handler(struct urb *urb)
 			struct pwc_frame_buf *fbuf = pdev->fill_buf;
 
 			if (pdev->vsync == 1) {
-				do_gettimeofday(&fbuf->vb.v4l2_buf.timestamp);
+				v4l2_get_timestamp(
+					&fbuf->vb.v4l2_buf.timestamp);
 				pdev->vsync = 2;
 			}
 
diff --git a/drivers/media/usb/s2255/s2255drv.c b/drivers/media/usb/s2255/s2255drv.c
index 8ebec0d..498c57e 100644
--- a/drivers/media/usb/s2255/s2255drv.c
+++ b/drivers/media/usb/s2255/s2255drv.c
@@ -593,7 +593,7 @@ static int s2255_got_frame(struct s2255_channel *channel, int jpgsize)
 	buf = list_entry(dma_q->active.next,
 			 struct s2255_buffer, vb.queue);
 	list_del(&buf->vb.queue);
-	do_gettimeofday(&buf->vb.ts);
+	v4l2_get_timestamp(&buf->vb.ts);
 	s2255_fillbuff(channel, buf, jpgsize);
 	wake_up(&buf->vb.done);
 	dprintk(2, "%s: [buf/i] [%p/%d]\n", __func__, buf, buf->vb.i);
@@ -629,7 +629,6 @@ static void s2255_fillbuff(struct s2255_channel *channel,
 			   struct s2255_buffer *buf, int jpgsize)
 {
 	int pos = 0;
-	struct timeval ts;
 	const char *tmpbuf;
 	char *vbuf = videobuf_to_vmalloc(&buf->vb);
 	unsigned long last_frame;
@@ -674,8 +673,7 @@ static void s2255_fillbuff(struct s2255_channel *channel,
 	/* tell v4l buffer was filled */
 
 	buf->vb.field_count = channel->frame_count * 2;
-	do_gettimeofday(&ts);
-	buf->vb.ts = ts;
+	v4l2_get_timestamp(&buf->vb.ts);
 	buf->vb.state = VIDEOBUF_DONE;
 }
 
diff --git a/drivers/media/usb/sn9c102/sn9c102_core.c b/drivers/media/usb/sn9c102/sn9c102_core.c
index 5bfc8e2..843fadc 100644
--- a/drivers/media/usb/sn9c102/sn9c102_core.c
+++ b/drivers/media/usb/sn9c102/sn9c102_core.c
@@ -773,7 +773,8 @@ end_of_frame:
 				       img);
 
 				if ((*f)->buf.bytesused == 0)
-					do_gettimeofday(&(*f)->buf.timestamp);
+					v4l2_get_timestamp(
+						&(*f)->buf.timestamp);
 
 				(*f)->buf.bytesused += img;
 
diff --git a/drivers/media/usb/stk1160/stk1160-video.c b/drivers/media/usb/stk1160/stk1160-video.c
index 8bdfb02..cbdb7de 100644
--- a/drivers/media/usb/stk1160/stk1160-video.c
+++ b/drivers/media/usb/stk1160/stk1160-video.c
@@ -101,7 +101,7 @@ void stk1160_buffer_done(struct stk1160 *dev)
 	buf->vb.v4l2_buf.sequence = dev->field_count >> 1;
 	buf->vb.v4l2_buf.field = V4L2_FIELD_INTERLACED;
 	buf->vb.v4l2_buf.bytesused = buf->bytesused;
-	do_gettimeofday(&buf->vb.v4l2_buf.timestamp);
+	v4l2_get_timestamp(&buf->vb.v4l2_buf.timestamp);
 
 	vb2_set_plane_payload(&buf->vb, 0, buf->bytesused);
 	vb2_buffer_done(&buf->vb, VB2_BUF_STATE_DONE);
diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c b/drivers/media/usb/stkwebcam/stk-webcam.c
index 86a0fc5..c22a4d0 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.c
+++ b/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -1116,7 +1116,7 @@ static int stk_vidioc_dqbuf(struct file *filp,
 	sbuf->v4lbuf.flags &= ~V4L2_BUF_FLAG_QUEUED;
 	sbuf->v4lbuf.flags |= V4L2_BUF_FLAG_DONE;
 	sbuf->v4lbuf.sequence = ++dev->sequence;
-	do_gettimeofday(&sbuf->v4lbuf.timestamp);
+	v4l2_get_timestamp(&sbuf->v4lbuf.timestamp);
 
 	*buf = sbuf->v4lbuf;
 	return 0;
diff --git a/drivers/media/usb/tlg2300/pd-video.c b/drivers/media/usb/tlg2300/pd-video.c
index 3082bfa..2172337 100644
--- a/drivers/media/usb/tlg2300/pd-video.c
+++ b/drivers/media/usb/tlg2300/pd-video.c
@@ -212,7 +212,7 @@ static void submit_frame(struct front_face *front)
 	front->curr_frame	= NULL;
 	vb->state		= VIDEOBUF_DONE;
 	vb->field_count++;
-	do_gettimeofday(&vb->ts);
+	v4l2_get_timestamp(&vb->ts);
 
 	wake_up(&vb->done);
 }
diff --git a/drivers/media/usb/tm6000/tm6000-video.c b/drivers/media/usb/tm6000/tm6000-video.c
index 4342cd4..f2b06a1 100644
--- a/drivers/media/usb/tm6000/tm6000-video.c
+++ b/drivers/media/usb/tm6000/tm6000-video.c
@@ -191,7 +191,7 @@ static inline void buffer_filled(struct tm6000_core *dev,
 	dprintk(dev, V4L2_DEBUG_ISOC, "[%p/%d] wakeup\n", buf, buf->vb.i);
 	buf->vb.state = VIDEOBUF_DONE;
 	buf->vb.field_count++;
-	do_gettimeofday(&buf->vb.ts);
+	v4l2_get_timestamp(&buf->vb.ts);
 
 	list_del(&buf->vb.queue);
 	wake_up(&buf->vb.done);
diff --git a/drivers/media/usb/usbvision/usbvision-core.c b/drivers/media/usb/usbvision/usbvision-core.c
index c9b2042..816b1cf 100644
--- a/drivers/media/usb/usbvision/usbvision-core.c
+++ b/drivers/media/usb/usbvision/usbvision-core.c
@@ -1169,7 +1169,7 @@ static void usbvision_parse_data(struct usb_usbvision *usbvision)
 
 	if (newstate == parse_state_next_frame) {
 		frame->grabstate = frame_state_done;
-		do_gettimeofday(&(frame->timestamp));
+		v4l2_get_timestamp(&(frame->timestamp));
 		frame->sequence = usbvision->frame_num;
 
 		spin_lock_irqsave(&usbvision->queue_lock, lock_flags);
diff --git a/drivers/media/usb/zr364xx/zr364xx.c b/drivers/media/usb/zr364xx/zr364xx.c
index 39edd44..74d56df 100644
--- a/drivers/media/usb/zr364xx/zr364xx.c
+++ b/drivers/media/usb/zr364xx/zr364xx.c
@@ -501,7 +501,6 @@ static void zr364xx_fillbuff(struct zr364xx_camera *cam,
 			     int jpgsize)
 {
 	int pos = 0;
-	struct timeval ts;
 	const char *tmpbuf;
 	char *vbuf = videobuf_to_vmalloc(&buf->vb);
 	unsigned long last_frame;
@@ -530,8 +529,7 @@ static void zr364xx_fillbuff(struct zr364xx_camera *cam,
 	/* tell v4l buffer was filled */
 
 	buf->vb.field_count = cam->frame_count * 2;
-	do_gettimeofday(&ts);
-	buf->vb.ts = ts;
+	v4l2_get_timestamp(&buf->vb.ts);
 	buf->vb.state = VIDEOBUF_DONE;
 }
 
@@ -559,7 +557,7 @@ static int zr364xx_got_frame(struct zr364xx_camera *cam, int jpgsize)
 		goto unlock;
 	}
 	list_del(&buf->vb.queue);
-	do_gettimeofday(&buf->vb.ts);
+	v4l2_get_timestamp(&buf->vb.ts);
 	DBG("[%p/%d] wakeup\n", buf, buf->vb.i);
 	zr364xx_fillbuff(cam, buf, jpgsize);
 	wake_up(&buf->vb.done);
-- 
1.7.2.5

Re: [PATCH 3/4] v4l: Convert drivers to use monotonic timestamps

[Hans Verkuil]

On Thu November 15 2012 23:06:46 Sakari Ailus wrote:
> Convert drivers using wall clock time (CLOCK_REALTIME) to timestamp from the
> monotonic timer (CLOCK_MONOTONIC).
> 
> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>

Acked-by: Hans Verkuil <hans.verkuil@cisco.com>

Regards,

	Hans

[PATCH 4/4] v4l: Tell user space we're using monotonic timestamps

[Sakari Ailus]

Set buffer timestamp flags for videobuf, videobuf2 and drivers that use
neither.

Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/media/pci/meye/meye.c                 |    4 ++--
 drivers/media/pci/zoran/zoran_driver.c        |    2 +-
 drivers/media/platform/omap3isp/ispqueue.c    |    1 +
 drivers/media/platform/vino.c                 |    3 +++
 drivers/media/usb/cpia2/cpia2_v4l.c           |    5 ++++-
 drivers/media/usb/sn9c102/sn9c102_core.c      |    2 +-
 drivers/media/usb/stkwebcam/stk-webcam.c      |    1 +
 drivers/media/usb/usbvision/usbvision-video.c |    5 +++--
 drivers/media/v4l2-core/videobuf-core.c       |    2 +-
 drivers/media/v4l2-core/videobuf2-core.c      |   10 ++++++----
 10 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/drivers/media/pci/meye/meye.c b/drivers/media/pci/meye/meye.c
index 288adea..ac7ab6e 100644
--- a/drivers/media/pci/meye/meye.c
+++ b/drivers/media/pci/meye/meye.c
@@ -1426,7 +1426,7 @@ static int vidioc_querybuf(struct file *file, void *fh, struct v4l2_buffer *buf)
 		return -EINVAL;
 
 	buf->bytesused = meye.grab_buffer[index].size;
-	buf->flags = V4L2_BUF_FLAG_MAPPED;
+	buf->flags = V4L2_BUF_FLAG_MAPPED | V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
 
 	if (meye.grab_buffer[index].state == MEYE_BUF_USING)
 		buf->flags |= V4L2_BUF_FLAG_QUEUED;
@@ -1499,7 +1499,7 @@ static int vidioc_dqbuf(struct file *file, void *fh, struct v4l2_buffer *buf)
 
 	buf->index = reqnr;
 	buf->bytesused = meye.grab_buffer[reqnr].size;
-	buf->flags = V4L2_BUF_FLAG_MAPPED;
+	buf->flags = V4L2_BUF_FLAG_MAPPED | V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
 	buf->field = V4L2_FIELD_NONE;
 	buf->timestamp = meye.grab_buffer[reqnr].timestamp;
 	buf->sequence = meye.grab_buffer[reqnr].sequence;
diff --git a/drivers/media/pci/zoran/zoran_driver.c b/drivers/media/pci/zoran/zoran_driver.c
index 53f12c7..33521a4 100644
--- a/drivers/media/pci/zoran/zoran_driver.c
+++ b/drivers/media/pci/zoran/zoran_driver.c
@@ -1334,7 +1334,7 @@ static int zoran_v4l2_buffer_status(struct zoran_fh *fh,
 	struct zoran *zr = fh->zr;
 	unsigned long flags;
 
-	buf->flags = V4L2_BUF_FLAG_MAPPED;
+	buf->flags = V4L2_BUF_FLAG_MAPPED | V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
 
 	switch (fh->map_mode) {
 	case ZORAN_MAP_MODE_RAW:
diff --git a/drivers/media/platform/omap3isp/ispqueue.c b/drivers/media/platform/omap3isp/ispqueue.c
index 15bf3ea..6599963 100644
--- a/drivers/media/platform/omap3isp/ispqueue.c
+++ b/drivers/media/platform/omap3isp/ispqueue.c
@@ -674,6 +674,7 @@ static int isp_video_queue_alloc(struct isp_video_queue *queue,
 		buf->vbuf.index = i;
 		buf->vbuf.length = size;
 		buf->vbuf.type = queue->type;
+		buf->vbuf.flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
 		buf->vbuf.field = V4L2_FIELD_NONE;
 		buf->vbuf.memory = memory;
 
diff --git a/drivers/media/platform/vino.c b/drivers/media/platform/vino.c
index 28350e7..eb5d6f9 100644
--- a/drivers/media/platform/vino.c
+++ b/drivers/media/platform/vino.c
@@ -3410,6 +3410,9 @@ static void vino_v4l2_get_buffer_status(struct vino_channel_settings *vcs,
 	if (fb->map_count > 0)
 		b->flags |= V4L2_BUF_FLAG_MAPPED;
 
+	b->flags &= ~V4L2_BUF_FLAG_TIMESTAMP_MASK;
+	b->flags |= V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
+
 	b->index = fb->id;
 	b->memory = (vcs->fb_queue.type == VINO_MEMORY_MMAP) ?
 		V4L2_MEMORY_MMAP : V4L2_MEMORY_USERPTR;
diff --git a/drivers/media/usb/cpia2/cpia2_v4l.c b/drivers/media/usb/cpia2/cpia2_v4l.c
index aeb9d22..d5d42b6 100644
--- a/drivers/media/usb/cpia2/cpia2_v4l.c
+++ b/drivers/media/usb/cpia2/cpia2_v4l.c
@@ -825,6 +825,8 @@ static int cpia2_querybuf(struct file *file, void *fh, struct v4l2_buffer *buf)
 	else
 		buf->flags = 0;
 
+	buf->flags |= V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
+
 	switch (cam->buffers[buf->index].status) {
 	case FRAME_EMPTY:
 	case FRAME_ERROR:
@@ -943,7 +945,8 @@ static int cpia2_dqbuf(struct file *file, void *fh, struct v4l2_buffer *buf)
 
 	buf->index = frame;
 	buf->bytesused = cam->buffers[buf->index].length;
-	buf->flags = V4L2_BUF_FLAG_MAPPED | V4L2_BUF_FLAG_DONE;
+	buf->flags = V4L2_BUF_FLAG_MAPPED | V4L2_BUF_FLAG_DONE
+		| V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
 	buf->field = V4L2_FIELD_NONE;
 	buf->timestamp = cam->buffers[buf->index].timestamp;
 	buf->sequence = cam->buffers[buf->index].seq;
diff --git a/drivers/media/usb/sn9c102/sn9c102_core.c b/drivers/media/usb/sn9c102/sn9c102_core.c
index 843fadc..2e0e2ff 100644
--- a/drivers/media/usb/sn9c102/sn9c102_core.c
+++ b/drivers/media/usb/sn9c102/sn9c102_core.c
@@ -173,7 +173,7 @@ sn9c102_request_buffers(struct sn9c102_device* cam, u32 count,
 		cam->frame[i].buf.sequence = 0;
 		cam->frame[i].buf.field = V4L2_FIELD_NONE;
 		cam->frame[i].buf.memory = V4L2_MEMORY_MMAP;
-		cam->frame[i].buf.flags = 0;
+		cam->frame[i].buf.flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
 	}
 
 	return cam->nbuffers;
diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c b/drivers/media/usb/stkwebcam/stk-webcam.c
index c22a4d0..459ebc6 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.c
+++ b/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -470,6 +470,7 @@ static int stk_setup_siobuf(struct stk_camera *dev, int index)
 	buf->dev = dev;
 	buf->v4lbuf.index = index;
 	buf->v4lbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+	buf->v4lbuf.flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
 	buf->v4lbuf.field = V4L2_FIELD_NONE;
 	buf->v4lbuf.memory = V4L2_MEMORY_MMAP;
 	buf->v4lbuf.m.offset = 2*index*buf->v4lbuf.length;
diff --git a/drivers/media/usb/usbvision/usbvision-video.c b/drivers/media/usb/usbvision/usbvision-video.c
index 5c36a57..c6bc8ce 100644
--- a/drivers/media/usb/usbvision/usbvision-video.c
+++ b/drivers/media/usb/usbvision/usbvision-video.c
@@ -761,7 +761,7 @@ static int vidioc_querybuf(struct file *file,
 	if (vb->index >= usbvision->num_frames)
 		return -EINVAL;
 	/* Updating the corresponding frame state */
-	vb->flags = 0;
+	vb->flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
 	frame = &usbvision->frame[vb->index];
 	if (frame->grabstate >= frame_state_ready)
 		vb->flags |= V4L2_BUF_FLAG_QUEUED;
@@ -843,7 +843,8 @@ static int vidioc_dqbuf(struct file *file, void *priv, struct v4l2_buffer *vb)
 	vb->memory = V4L2_MEMORY_MMAP;
 	vb->flags = V4L2_BUF_FLAG_MAPPED |
 		V4L2_BUF_FLAG_QUEUED |
-		V4L2_BUF_FLAG_DONE;
+		V4L2_BUF_FLAG_DONE |
+		V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
 	vb->index = f->index;
 	vb->sequence = f->sequence;
 	vb->timestamp = f->timestamp;
diff --git a/drivers/media/v4l2-core/videobuf-core.c b/drivers/media/v4l2-core/videobuf-core.c
index bf7a326..e98db7e 100644
--- a/drivers/media/v4l2-core/videobuf-core.c
+++ b/drivers/media/v4l2-core/videobuf-core.c
@@ -337,7 +337,7 @@ static void videobuf_status(struct videobuf_queue *q, struct v4l2_buffer *b,
 		break;
 	}
 
-	b->flags    = 0;
+	b->flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
 	if (vb->map)
 		b->flags |= V4L2_BUF_FLAG_MAPPED;
 
diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c
index 432df11..19a5866 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -40,9 +40,10 @@ module_param(debug, int, 0644);
 #define call_qop(q, op, args...)					\
 	(((q)->ops->op) ? ((q)->ops->op(args)) : 0)
 
-#define V4L2_BUFFER_STATE_FLAGS	(V4L2_BUF_FLAG_MAPPED | V4L2_BUF_FLAG_QUEUED | \
+#define V4L2_BUFFER_MASK_FLAGS	(V4L2_BUF_FLAG_MAPPED | V4L2_BUF_FLAG_QUEUED | \
 				 V4L2_BUF_FLAG_DONE | V4L2_BUF_FLAG_ERROR | \
-				 V4L2_BUF_FLAG_PREPARED)
+				 V4L2_BUF_FLAG_PREPARED | \
+				 V4L2_BUF_FLAG_TIMESTAMP_MASK)
 
 /**
  * __vb2_buf_mem_alloc() - allocate video memory for the given buffer
@@ -367,7 +368,8 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, struct v4l2_buffer *b)
 	/*
 	 * Clear any buffer state related flags.
 	 */
-	b->flags &= ~V4L2_BUFFER_STATE_FLAGS;
+	b->flags &= ~V4L2_BUFFER_MASK_FLAGS;
+	b->flags |= V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
 
 	switch (vb->state) {
 	case VB2_BUF_STATE_QUEUED:
@@ -863,7 +865,7 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b
 
 	vb->v4l2_buf.field = b->field;
 	vb->v4l2_buf.timestamp = b->timestamp;
-	vb->v4l2_buf.flags = b->flags & ~V4L2_BUFFER_STATE_FLAGS;
+	vb->v4l2_buf.flags = b->flags & ~V4L2_BUFFER_MASK_FLAGS;
 }
 
 /**
-- 
1.7.2.5

Re: [PATCH 4/4] v4l: Tell user space we're using monotonic timestamps

[Hans Verkuil]

On Thu November 15 2012 23:06:47 Sakari Ailus wrote:
> Set buffer timestamp flags for videobuf, videobuf2 and drivers that use
> neither.
> 
> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
>  drivers/media/pci/meye/meye.c                 |    4 ++--
>  drivers/media/pci/zoran/zoran_driver.c        |    2 +-
>  drivers/media/platform/omap3isp/ispqueue.c    |    1 +
>  drivers/media/platform/vino.c                 |    3 +++
>  drivers/media/usb/cpia2/cpia2_v4l.c           |    5 ++++-
>  drivers/media/usb/sn9c102/sn9c102_core.c      |    2 +-
>  drivers/media/usb/stkwebcam/stk-webcam.c      |    1 +
>  drivers/media/usb/usbvision/usbvision-video.c |    5 +++--
>  drivers/media/v4l2-core/videobuf-core.c       |    2 +-
>  drivers/media/v4l2-core/videobuf2-core.c      |   10 ++++++----
>  10 files changed, 23 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/media/pci/meye/meye.c b/drivers/media/pci/meye/meye.c
> index 288adea..ac7ab6e 100644
> --- a/drivers/media/pci/meye/meye.c
> +++ b/drivers/media/pci/meye/meye.c
> @@ -1426,7 +1426,7 @@ static int vidioc_querybuf(struct file *file, void *fh, struct v4l2_buffer *buf)
>  		return -EINVAL;
>  
>  	buf->bytesused = meye.grab_buffer[index].size;
> -	buf->flags = V4L2_BUF_FLAG_MAPPED;
> +	buf->flags = V4L2_BUF_FLAG_MAPPED | V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
>  
>  	if (meye.grab_buffer[index].state == MEYE_BUF_USING)
>  		buf->flags |= V4L2_BUF_FLAG_QUEUED;
> @@ -1499,7 +1499,7 @@ static int vidioc_dqbuf(struct file *file, void *fh, struct v4l2_buffer *buf)
>  
>  	buf->index = reqnr;
>  	buf->bytesused = meye.grab_buffer[reqnr].size;
> -	buf->flags = V4L2_BUF_FLAG_MAPPED;
> +	buf->flags = V4L2_BUF_FLAG_MAPPED | V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
>  	buf->field = V4L2_FIELD_NONE;
>  	buf->timestamp = meye.grab_buffer[reqnr].timestamp;
>  	buf->sequence = meye.grab_buffer[reqnr].sequence;
> diff --git a/drivers/media/pci/zoran/zoran_driver.c b/drivers/media/pci/zoran/zoran_driver.c
> index 53f12c7..33521a4 100644
> --- a/drivers/media/pci/zoran/zoran_driver.c
> +++ b/drivers/media/pci/zoran/zoran_driver.c
> @@ -1334,7 +1334,7 @@ static int zoran_v4l2_buffer_status(struct zoran_fh *fh,
>  	struct zoran *zr = fh->zr;
>  	unsigned long flags;
>  
> -	buf->flags = V4L2_BUF_FLAG_MAPPED;
> +	buf->flags = V4L2_BUF_FLAG_MAPPED | V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
>  
>  	switch (fh->map_mode) {
>  	case ZORAN_MAP_MODE_RAW:
> diff --git a/drivers/media/platform/omap3isp/ispqueue.c b/drivers/media/platform/omap3isp/ispqueue.c
> index 15bf3ea..6599963 100644
> --- a/drivers/media/platform/omap3isp/ispqueue.c
> +++ b/drivers/media/platform/omap3isp/ispqueue.c
> @@ -674,6 +674,7 @@ static int isp_video_queue_alloc(struct isp_video_queue *queue,
>  		buf->vbuf.index = i;
>  		buf->vbuf.length = size;
>  		buf->vbuf.type = queue->type;
> +		buf->vbuf.flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
>  		buf->vbuf.field = V4L2_FIELD_NONE;
>  		buf->vbuf.memory = memory;
>  
> diff --git a/drivers/media/platform/vino.c b/drivers/media/platform/vino.c
> index 28350e7..eb5d6f9 100644
> --- a/drivers/media/platform/vino.c
> +++ b/drivers/media/platform/vino.c
> @@ -3410,6 +3410,9 @@ static void vino_v4l2_get_buffer_status(struct vino_channel_settings *vcs,
>  	if (fb->map_count > 0)
>  		b->flags |= V4L2_BUF_FLAG_MAPPED;
>  
> +	b->flags &= ~V4L2_BUF_FLAG_TIMESTAMP_MASK;
> +	b->flags |= V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
> +
>  	b->index = fb->id;
>  	b->memory = (vcs->fb_queue.type == VINO_MEMORY_MMAP) ?
>  		V4L2_MEMORY_MMAP : V4L2_MEMORY_USERPTR;
> diff --git a/drivers/media/usb/cpia2/cpia2_v4l.c b/drivers/media/usb/cpia2/cpia2_v4l.c
> index aeb9d22..d5d42b6 100644
> --- a/drivers/media/usb/cpia2/cpia2_v4l.c
> +++ b/drivers/media/usb/cpia2/cpia2_v4l.c
> @@ -825,6 +825,8 @@ static int cpia2_querybuf(struct file *file, void *fh, struct v4l2_buffer *buf)
>  	else
>  		buf->flags = 0;
>  
> +	buf->flags |= V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
> +
>  	switch (cam->buffers[buf->index].status) {
>  	case FRAME_EMPTY:
>  	case FRAME_ERROR:
> @@ -943,7 +945,8 @@ static int cpia2_dqbuf(struct file *file, void *fh, struct v4l2_buffer *buf)
>  
>  	buf->index = frame;
>  	buf->bytesused = cam->buffers[buf->index].length;
> -	buf->flags = V4L2_BUF_FLAG_MAPPED | V4L2_BUF_FLAG_DONE;
> +	buf->flags = V4L2_BUF_FLAG_MAPPED | V4L2_BUF_FLAG_DONE
> +		| V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
>  	buf->field = V4L2_FIELD_NONE;
>  	buf->timestamp = cam->buffers[buf->index].timestamp;
>  	buf->sequence = cam->buffers[buf->index].seq;
> diff --git a/drivers/media/usb/sn9c102/sn9c102_core.c b/drivers/media/usb/sn9c102/sn9c102_core.c
> index 843fadc..2e0e2ff 100644
> --- a/drivers/media/usb/sn9c102/sn9c102_core.c
> +++ b/drivers/media/usb/sn9c102/sn9c102_core.c
> @@ -173,7 +173,7 @@ sn9c102_request_buffers(struct sn9c102_device* cam, u32 count,
>  		cam->frame[i].buf.sequence = 0;
>  		cam->frame[i].buf.field = V4L2_FIELD_NONE;
>  		cam->frame[i].buf.memory = V4L2_MEMORY_MMAP;
> -		cam->frame[i].buf.flags = 0;
> +		cam->frame[i].buf.flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
>  	}
>  
>  	return cam->nbuffers;
> diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c b/drivers/media/usb/stkwebcam/stk-webcam.c
> index c22a4d0..459ebc6 100644
> --- a/drivers/media/usb/stkwebcam/stk-webcam.c
> +++ b/drivers/media/usb/stkwebcam/stk-webcam.c
> @@ -470,6 +470,7 @@ static int stk_setup_siobuf(struct stk_camera *dev, int index)
>  	buf->dev = dev;
>  	buf->v4lbuf.index = index;
>  	buf->v4lbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> +	buf->v4lbuf.flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
>  	buf->v4lbuf.field = V4L2_FIELD_NONE;
>  	buf->v4lbuf.memory = V4L2_MEMORY_MMAP;
>  	buf->v4lbuf.m.offset = 2*index*buf->v4lbuf.length;
> diff --git a/drivers/media/usb/usbvision/usbvision-video.c b/drivers/media/usb/usbvision/usbvision-video.c
> index 5c36a57..c6bc8ce 100644
> --- a/drivers/media/usb/usbvision/usbvision-video.c
> +++ b/drivers/media/usb/usbvision/usbvision-video.c
> @@ -761,7 +761,7 @@ static int vidioc_querybuf(struct file *file,
>  	if (vb->index >= usbvision->num_frames)
>  		return -EINVAL;
>  	/* Updating the corresponding frame state */
> -	vb->flags = 0;
> +	vb->flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
>  	frame = &usbvision->frame[vb->index];
>  	if (frame->grabstate >= frame_state_ready)
>  		vb->flags |= V4L2_BUF_FLAG_QUEUED;
> @@ -843,7 +843,8 @@ static int vidioc_dqbuf(struct file *file, void *priv, struct v4l2_buffer *vb)
>  	vb->memory = V4L2_MEMORY_MMAP;
>  	vb->flags = V4L2_BUF_FLAG_MAPPED |
>  		V4L2_BUF_FLAG_QUEUED |
> -		V4L2_BUF_FLAG_DONE;
> +		V4L2_BUF_FLAG_DONE |
> +		V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
>  	vb->index = f->index;
>  	vb->sequence = f->sequence;
>  	vb->timestamp = f->timestamp;
> diff --git a/drivers/media/v4l2-core/videobuf-core.c b/drivers/media/v4l2-core/videobuf-core.c
> index bf7a326..e98db7e 100644
> --- a/drivers/media/v4l2-core/videobuf-core.c
> +++ b/drivers/media/v4l2-core/videobuf-core.c
> @@ -337,7 +337,7 @@ static void videobuf_status(struct videobuf_queue *q, struct v4l2_buffer *b,
>  		break;
>  	}
>  
> -	b->flags    = 0;
> +	b->flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
>  	if (vb->map)
>  		b->flags |= V4L2_BUF_FLAG_MAPPED;
>  
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c
> index 432df11..19a5866 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -40,9 +40,10 @@ module_param(debug, int, 0644);
>  #define call_qop(q, op, args...)					\
>  	(((q)->ops->op) ? ((q)->ops->op(args)) : 0)
>  
> -#define V4L2_BUFFER_STATE_FLAGS	(V4L2_BUF_FLAG_MAPPED | V4L2_BUF_FLAG_QUEUED | \
> +#define V4L2_BUFFER_MASK_FLAGS	(V4L2_BUF_FLAG_MAPPED | V4L2_BUF_FLAG_QUEUED | \
>  				 V4L2_BUF_FLAG_DONE | V4L2_BUF_FLAG_ERROR | \
> -				 V4L2_BUF_FLAG_PREPARED)
> +				 V4L2_BUF_FLAG_PREPARED | \
> +				 V4L2_BUF_FLAG_TIMESTAMP_MASK)
>  
>  /**
>   * __vb2_buf_mem_alloc() - allocate video memory for the given buffer
> @@ -367,7 +368,8 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, struct v4l2_buffer *b)
>  	/*
>  	 * Clear any buffer state related flags.
>  	 */
> -	b->flags &= ~V4L2_BUFFER_STATE_FLAGS;
> +	b->flags &= ~V4L2_BUFFER_MASK_FLAGS;
> +	b->flags |= V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
>  
>  	switch (vb->state) {
>  	case VB2_BUF_STATE_QUEUED:
> @@ -863,7 +865,7 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b
>  
>  	vb->v4l2_buf.field = b->field;
>  	vb->v4l2_buf.timestamp = b->timestamp;
> -	vb->v4l2_buf.flags = b->flags & ~V4L2_BUFFER_STATE_FLAGS;
> +	vb->v4l2_buf.flags = b->flags & ~V4L2_BUFFER_MASK_FLAGS;
>  }
>  
>  /**
> 

Acked-by: Hans Verkuil <hans.verkuil@cisco.com>

Regards,

	Hans

RE: [PATCH 4/4] v4l: Tell user space we're using monotonic timestamps

[Kamil Debski]

Hi Hans, Sakari,

A quick question follows inline.

[snip]

> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> > b/drivers/media/v4l2-core/videobuf2-core.c
> > index 432df11..19a5866 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -40,9 +40,10 @@ module_param(debug, int, 0644);
> >  #define call_qop(q, op, args...)					\
> >  	(((q)->ops->op) ? ((q)->ops->op(args)) : 0)
> >
> > -#define V4L2_BUFFER_STATE_FLAGS	(V4L2_BUF_FLAG_MAPPED |
> V4L2_BUF_FLAG_QUEUED | \
> > +#define V4L2_BUFFER_MASK_FLAGS	(V4L2_BUF_FLAG_MAPPED |
> V4L2_BUF_FLAG_QUEUED | \
> >  				 V4L2_BUF_FLAG_DONE | V4L2_BUF_FLAG_ERROR |
\
> > -				 V4L2_BUF_FLAG_PREPARED)
> > +				 V4L2_BUF_FLAG_PREPARED | \
> > +				 V4L2_BUF_FLAG_TIMESTAMP_MASK)
> >
> >  /**
> >   * __vb2_buf_mem_alloc() - allocate video memory for the given
> buffer
> > @@ -367,7 +368,8 @@ static void __fill_v4l2_buffer(struct vb2_buffer
> *vb, struct v4l2_buffer *b)
> >  	/*
> >  	 * Clear any buffer state related flags.
> >  	 */
> > -	b->flags &= ~V4L2_BUFFER_STATE_FLAGS;
> > +	b->flags &= ~V4L2_BUFFER_MASK_FLAGS;
> > +	b->flags |= V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;

As far as I know, after __fill_v4l2_buffer is run driver has no means
to change flags. Right?

So how should a driver, which is not using the MONOTONIC timestamps inform
the user space about it?

> >
> >  	switch (vb->state) {
> >  	case VB2_BUF_STATE_QUEUED:
> > @@ -863,7 +865,7 @@ static void __fill_vb2_buffer(struct vb2_buffer
> > *vb, const struct v4l2_buffer *b
> >
> >  	vb->v4l2_buf.field = b->field;
> >  	vb->v4l2_buf.timestamp = b->timestamp;
> > -	vb->v4l2_buf.flags = b->flags & ~V4L2_BUFFER_STATE_FLAGS;
> > +	vb->v4l2_buf.flags = b->flags & ~V4L2_BUFFER_MASK_FLAGS;
> >  }
> >
> >  /**
> >
> 
> Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
> 

Best wishes,
-- 
Kamil Debski
Linux Platform Group
Samsung Poland R&D Center

Re: [PATCH 4/4] v4l: Tell user space we're using monotonic timestamps

['Sakari Ailus']

Hi Kamil,

On Mon, Dec 17, 2012 at 12:19:51PM +0100, Kamil Debski wrote:
...
> > > @@ -367,7 +368,8 @@ static void __fill_v4l2_buffer(struct vb2_buffer
> > *vb, struct v4l2_buffer *b)
> > >  	/*
> > >  	 * Clear any buffer state related flags.
> > >  	 */
> > > -	b->flags &= ~V4L2_BUFFER_STATE_FLAGS;
> > > +	b->flags &= ~V4L2_BUFFER_MASK_FLAGS;
> > > +	b->flags |= V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
> 
> As far as I know, after __fill_v4l2_buffer is run driver has no means
> to change flags. Right?

Correct. Querybuf, for example, is implemented in vb2 and no driver
involvement is required. And we sure don't want to add it. ;)

> So how should a driver, which is not using the MONOTONIC timestamps inform
> the user space about it?

We currently support only monotonic timestamps. Support for different kind
of timestamps should be added to videobuf2 when they are needed. The drivers
would then be using a videobuf2 equivalent of v4l2_get_timestamp().

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

RE: [PATCH 4/4] v4l: Tell user space we're using monotonic timestamps

[Kamil Debski]

> From: 'Sakari Ailus' [mailto:sakari.ailus@iki.fi]
> Sent: Monday, December 17, 2012 12:35 PM
> Subject: Re: [PATCH 4/4] v4l: Tell user space we're using monotonic
> timestamps
> 
> Hi Kamil,
> 
> On Mon, Dec 17, 2012 at 12:19:51PM +0100, Kamil Debski wrote:
> ...
> > > > @@ -367,7 +368,8 @@ static void __fill_v4l2_buffer(struct
> > > > vb2_buffer
> > > *vb, struct v4l2_buffer *b)
> > > >  	/*
> > > >  	 * Clear any buffer state related flags.
> > > >  	 */
> > > > -	b->flags &= ~V4L2_BUFFER_STATE_FLAGS;
> > > > +	b->flags &= ~V4L2_BUFFER_MASK_FLAGS;
> > > > +	b->flags |= V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
> >
> > As far as I know, after __fill_v4l2_buffer is run driver has no means
> > to change flags. Right?
> 
> Correct. Querybuf, for example, is implemented in vb2 and no driver
> involvement is required. And we sure don't want to add it. ;)

I did not suggest that it should be added.

> 
> > So how should a driver, which is not using the MONOTONIC timestamps
> > inform the user space about it?
> 
> We currently support only monotonic timestamps. Support for different
> kind of timestamps should be added to videobuf2 when they are needed.
> The drivers would then be using a videobuf2 equivalent of
> v4l2_get_timestamp().

Just as I though.
Mind you - v4l2_get_timestamp() does not apply if the timestamp are simply
copied.
This is the case of some of the mem2mem devices, remember?

Best wishes,
--
Kamil Debski
Linux Platform Group
Samsung Poland R&D Center

Re: [PATCH 4/4] v4l: Tell user space we're using monotonic timestamps

[Sakari Ailus]

Hi Kamil,

On Mon, Dec 17, 2012 at 12:48:25PM +0100, Kamil Debski wrote:
> > From: 'Sakari Ailus' [mailto:sakari.ailus@iki.fi]
> > Sent: Monday, December 17, 2012 12:35 PM
> > Subject: Re: [PATCH 4/4] v4l: Tell user space we're using monotonic
> > timestamps
> > 
> > Hi Kamil,
> > 
> > On Mon, Dec 17, 2012 at 12:19:51PM +0100, Kamil Debski wrote:
> > ...
> > > > > @@ -367,7 +368,8 @@ static void __fill_v4l2_buffer(struct
> > > > > vb2_buffer
> > > > *vb, struct v4l2_buffer *b)
> > > > >  	/*
> > > > >  	 * Clear any buffer state related flags.
> > > > >  	 */
> > > > > -	b->flags &= ~V4L2_BUFFER_STATE_FLAGS;
> > > > > +	b->flags &= ~V4L2_BUFFER_MASK_FLAGS;
> > > > > +	b->flags |= V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
> > >
> > > As far as I know, after __fill_v4l2_buffer is run driver has no means
> > > to change flags. Right?
> > 
> > Correct. Querybuf, for example, is implemented in vb2 and no driver
> > involvement is required. And we sure don't want to add it. ;)
> 
> I did not suggest that it should be added.

Good. :-)

> > 
> > > So how should a driver, which is not using the MONOTONIC timestamps
> > > inform the user space about it?
> > 
> > We currently support only monotonic timestamps. Support for different
> > kind of timestamps should be added to videobuf2 when they are needed.
> > The drivers would then be using a videobuf2 equivalent of
> > v4l2_get_timestamp().
> 
> Just as I though.
> Mind you - v4l2_get_timestamp() does not apply if the timestamp are simply
> copied.
> This is the case of some of the mem2mem devices, remember?

Yeah. Makes sense.

I guess memory-to-memory devices (apart from possibly those dealing with
compressed data which contains the timestamps) should just copy the
timestamps from output to capture buffers.

-- 
Cheers,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk