Messages in this thread | | | From | Tomasz Figa <> | Date | Thu, 6 Feb 2020 17:51:46 +0900 | Subject | Re: [RFC][PATCH 12/15] videobuf2: add begin/end cpu_access callbacks to dma-sg |
| |
On Tue, Feb 4, 2020 at 11:50 AM Sergey Senozhatsky <senozhatsky@chromium.org> wrote: > > On (20/02/03 19:04), Tomasz Figa wrote: > [..] > > > I very much agree with that. But this should be very clearly documented. > > > Should V4L2_CAP_MEMORY_NON_CONSISTENT always be set in this case? > > > > > > > Yes, IMHO that would make sense. My understanding is that currently > > the consistency of allocated memory is unspecified, so it can be > > either. With V4L2_FLAG_MEMORY_NON_CONSISTENT, the userspace can > > explicitly ask for inconsistent memory. > > > > Moreover, I'd vote for setting V4L2_CAP_MEMORY_NON_CONSISTENT when > > V4L2_FLAG_MEMORY_NON_CONSISTENT is guaranteed to return inconsistent > > memory to avoid "optional" features or "hints" without guaranteed > > behavior. > > Documentation/DMA-attributes.txt says the following > > DMA_ATTR_NON_CONSISTENT > ----------------------- > > DMA_ATTR_NON_CONSISTENT lets the platform to choose to return either > consistent or non-consistent memory as it sees fit. By using this API, > you are guaranteeing to the platform that you have all the correct and > necessary sync points for this memory in the driver.
Good point. And I also realized that some platforms just have no way to make the memory inconsistent, because they may have hardware coherency.
Then we need to keep it a hint only.
Best regards, Tomasz
| |