Re: [PATCH 3/3] v4l: Set proper timestamp type in selected drivers which use videobuf2

[Sylwester Nawrocki <s.nawrocki@samsung.com>]

Hi,

On 01/21/2013 03:07 PM, Kamil Debski wrote:
>> How about making MONOTONIC timestamps default instead, or at least
>> assigning all drivers something else than UNKNOWN?
> 
> So why did you add the UNKNOWN flag?
> 
> The way I see it - UNKNOWN is the default and the one who coded the driver
> will set it to either MONOTONIC or COPY if it is one of these two. It won't
> be changed otherwise. There are drivers, which do not fill the timestamp
> field
> at all:
> - drivers/media/platform/coda.c
> - drivers/media/platform/exynos-gsc/gsc-m2m.c

Hmm, there is already a patch queued for this driver. It was intended
for v3.8 but has been delayed to 3.9.

http://git.linuxtv.org/media_tree.git/commitdiff/f60e160e126bdd8f0d928cd8b3fce54659597394

> - drivers/media/platform/m2m-deinterlace.c
> - drivers/media/platform/mx2_emmaprp.c
> - drivers/media/platform/s5p-fimc/fimc-m2m.c
> - drivers/media/platform/s5p-g2d.c
> - drivers/media/platform/s5p-jpeg/jpeg-core.c
>  
> The way you did it in your patches left no room for any kind of choice. I
> did
> comment at least twice about mem-2-mem devices in your RFCs, if I remember
> correctly. I think Sylwester was also writing about this. 
> Still everything got marked as MONOTONIC. 
> 
> If we were to assume that there were no other timestamp types then monotonic
> (which is not true, but this was your assumption), then what was the reason
> to add this timestamp framework?

Hmm, we could likely leave MONOTONIC as the default timestamp type. It
doesn't really matter what is the default, as long as drivers are provided
with an API to override it.

The reason why the above drivers don't do anything with v4l2_buffer::timestamp
field is there is no clear definitions at the specification for mem-to-mem
devices. We are working here on a Video Memory-to-memory Interface DocBook
documentation.

I think we will need a way to tell user space that timestamps are copied
from OUTPUT to CAPTURE buffer queue. At least that's what seems more
useful for applications. i.e. copying timestamps, rather than filling them
with the monotonic clock value.

OTOH I'm not certain what's the main purpose of such copied timestamps, is
it to identify which CAPTURE buffer comes from which OUTPUT buffer ?

--

Regards,
Sylwester