Hello!

We have been facing the problem of sync()ing buffers before performing
operations on them.

This is the current buffer life cycle in videobuf (for streaming, slightly
simplified):

- qbuf:
  buf_prepare, from which drivers call videobuf_iolock() if the state is
  VIDEOBUF_NEEDS_INIT (i.e. once per streamon)

- dqbuf:
  where per-memory method sync() is called

- streamoff:
  where buffers are released (i.e. iolock is "released")


We are working with devices that have a non-coherent cache (ARM-based).
For them sync()ing means flushing CPU cache for the physical memory to
contain valid data. We require syncing buffers not only after, but before
running the operation as well.

For CAPTURE devices this prevents corruption in case a flush occurs after
the operation has finished and overwrites the results with old data (from
before the operation).

For OUTPUT-type devices sync()ing is even more important, as the source
data may be completely invalid before the operation - before DMA can
be started, CPU cache has to be flushed.


We have divided sync operations into the following types:
- sync CAPTURE buffers before the operation
- sync CAPTURE buffers after the operation
- sync OUTPUT buffers before the operation

Our idea is to add an additional sync() call to videobuf_qbuf and
a parameter that would allow differentiating between syncs before and
after the operation. Alternatively, an additional function for that
could be added, if we don't want to change the API.

Please note that this is different from iolock(). Iolock is performed
once per streamon and what we need is a sync (which should also be
more lightweight than a full iolock) per each qbuf.

I would be grateful for your opinions on this topic. We'd like to
propose a patch if we come to an agreement on this as well.
Thank you!


Best regards
--
Pawel Osciak
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to