Hi, > From: Sylwester Nawrocki [mailto:s.nawrocki@xxxxxxxxxxx] > Sent: Tuesday, January 22, 2013 11:38 AM > > 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/f60e160e126bdd8f0d928c > d8b3fce54659597394 > > > - 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 ? > Yes, indeed. This is especially useful when the CAPTURE buffers can be returned in an order different than the order of corresponding OUTPUT buffers. Best wishes, -- Kamil Debski Linux Platform Group Samsung Poland R&D Center -- 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
