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. Regards, Hans -- 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
