Le mercredi 20 juillet 2016 à 16:20 +0300, Sakari Ailus a écrit : > Hi Javier, > > On Fri, Jul 15, 2016 at 12:26:06PM -0400, Javier Martinez Canillas > wrote: > > The buffer planes' dma-buf are currently mapped when buffers are queued > > from userspace but it's more appropriate to do the mapping when buffers > > are queued in the driver since that's when the actual DMA operation are > > going to happen. > > > > Suggested-by: Nicolas Dufresne <nicolas.dufresne@xxxxxxxxxxxxx> > > Signed-off-by: Javier Martinez Canillas <javier@xxxxxxxxxxxxxxx> > > > > --- > > > > Hello, > > > > A side effect of this change is that if the dmabuf map fails for some > > reasons (i.e: a driver using the DMA contig memory allocator but CMA > > not being enabled), the fail will no longer happen on VIDIOC_QBUF but > > later (i.e: in VIDIOC_STREAMON). > > > > I don't know if that's an issue though but I think is worth mentioning. > > I have the same question has Hans --- why? > > I rather think we should keep the buffers mapped all the time. That'd > require a bit of extra from the DMA-BUF framework I suppose, to support > streaming mappings. > > The reason for that is performance. If you're passing the buffer between a > couple of hardware devices, there's no need to map and unmap it every time > the buffer is accessed by the said devices. That'd avoid an unnecessary > cache flush as well, something that tends to be quite expensive. On a PC > with resolutions typically used on webcams that might not really matter. But > if you have an embedded system with a relatively modest 10 MP camera sensor, > it's one of the first things you'll notice if you check where the CPU time > is being spent. That is very interesting since the initial discussion started from the idea of adding an implicit fence wait to the map operation. This way we could have a dma-buf fence attached without having to modify the drivers to support it. Buffer handles could be dispatched before there is any data in it. Though, if we keep it mapped, I believe this idea is simply incompatible and fences should remain explicit for extra flexibility.
Attachment:
signature.asc
Description: This is a digitally signed message part
