Re: DMA-buf and uncached system memory

[Nicolas Dufresne]

Hi,

Le jeudi 23 juin 2022 à 10:58 +0200, Lucas Stach a écrit :
> > > In the DMA API keeping things mapped is also a valid use-case, but then
> > > you need to do explicit domain transfers via the dma_sync_* family,
> > > which DMA-buf has not inherited. Again those sync are no-ops on cache
> > > coherent architectures, but do any necessary cache maintenance on non
> > > coherent arches.
> > 
> > Correct, yes. Coherency is mandatory for DMA-buf, you can't use 
> > dma_sync_* on it when you are the importer.
> > 
> > The exporter could of course make use of that because he is the owner of 
> > the buffer.
> 
> In the example given here with UVC video, you don't know that the
> buffer will be exported and needs to be coherent without
> synchronization points, due to the mapping cache at the DRM side. So
> V4L2 naturally allocates the buffers from CPU cached memory. If the
> expectation is that those buffers are device coherent without relying
> on the map/unmap_attachment calls, then V4L2 needs to always
> synchronize caches on DQBUF when the  buffer is allocated from CPU
> cached memory and a single DMA-buf attachment exists. And while writing
> this I realize that this is probably exactly what V4L2 should do...

I'm not sure we are making any progress here. Doing so will just regress
performance of coherent devices used to render UVC video feeds. In fact, they
are all coherent except the display controller (on Intel). What my colleague was
suggesting me to try (with the expectation that some adaptation will be needed,
perhaps new signalling flags), is to read the dma_coherency_mask values on the
devices that calls attach() and adapt v4l2 exporter accordingly.

Its likely wrong as-is, not intended to be used for that, but the value is that
it tries to fix the problem, unlike what I'm reading here.

Nicolas