Hans Verkuil wrote: > On 02/15/2014 09:53 PM, Sakari Ailus wrote: >> The buffer flags field is 32 bits but the defined only used 16. This is >> fine, but as more than 16 bits will be used in the very near future, define >> them as 32-bit numbers for consistency. >> >> Signed-off-by: Sakari Ailus <sakari.ailus@xxxxxx> >> --- >> Documentation/DocBook/media/v4l/io.xml | 30 ++++++++++++------------- >> include/uapi/linux/videodev2.h | 38 +++++++++++++++++++------------- >> 2 files changed, 38 insertions(+), 30 deletions(-) >> >> diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml >> index 8facac4..46d24b3 100644 >> --- a/Documentation/DocBook/media/v4l/io.xml >> +++ b/Documentation/DocBook/media/v4l/io.xml > > <snip> > >> @@ -1115,7 +1115,7 @@ in which case caches have not been used.</entry> >> </row> >> <row> >> <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant></entry> >> - <entry>0x4000</entry> >> + <entry>0x00004000</entry> >> <entry>The CAPTURE buffer timestamp has been taken from the >> corresponding OUTPUT buffer. This flag applies only to mem2mem devices.</entry> >> </row> > > Should we add here that if TIMESTAMP_COPY is set and the TIMECODE flag is set, > then drivers should copy the TIMECODE struct as well? This is happening already > in various drivers and I think that is appropriate. Although to be honest nobody > is actually using the timecode struct, but we plan to hijack that for hardware > timestamps in the future anyway. Is there a single driver which uses the timecode field? The fact is that many m2m drivers copy it but that's probably mostly copying what one of them happened to do by accident. :-) -- Sakari Ailus sakari.ailus@xxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
