Le mardi 07 juin 2022 à 18:57 +0900, Sergey Senozhatsky a écrit : > On (22/06/01 11:13), Nicolas Dufresne wrote: > > I'd be very interested to learn from Sergey on why this feature wasn't enable > > more broadly. > > Well, we needed this for one particular device and we didn't plan on > expanding this to drivers that we cannot test, verify, etc. and for > the hardware that we don't run. Fair enough, should have been better documented, as folks may expect more then a single driver supporting it. I'll see if I can improve this. Justin's use case it to improve performance of software conversion of HW decoded frames. So he's only reading the buffer, so dmabuf/mmap is not as relevant here. > > > I notice though the begin/end access bits have not been > > implemented, so when used with DMABuf, this isn't going to behave quite right by > > default. > > We cared only for MMAP buffers. Got time to cook patches? Eventually, my ultimate goal is try and complete the DMABuf support in V4L2, this code you added in the contiguous allocator also exist in the SG and vmalloc one in some form (and is pretty generic), and both are also missing the begin/end ops for DMABuf (only works for MMAP), including tracking the attached device coherency. If that code was complete, I think we could eventually make this feature available by default (but not turned on, as I suspect flush overhead will regress some use cases). The memory synchronization support we have now is all for MMAP, and is in general very inefficient for DMABuf were we know more about the importer. Most devs seems to have avoided this problem. I felt like your hint work was part of it, but of course, if you were not using DMABuf, those hints are needed in replacement to DMABuf Sync API (which can be used for the same purpose). Perhaps not great that we duplicate modern API into legacy kind of APIs, but as long as V4L2 supports mmap, there is little choice but to do that. Nicolas
