Re: [PATCH v2 0/3] media: synchronize CPU access to imported DMA-BUFs

["Christian König" <christian.koenig@amd.com>]

On 11/12/26 04:16, Karl Mehltretter wrote:
> On Sat, Nov 07, 2026 at 12:59:46PM +0100, Laurent Pinchart wrote:
>> Hi Karl,
>>
>> We discussed in v1 how this is not the right approach. Why are you
>> posting a v2 without addressing that ? You need to go back to the design
>> table.
>>
> 
> v1 ended with two conflicting positions on non-coherent DMA-BUFs:
> 
> - Laurent [1] and Nicolas [2]: end_cpu_access(WRITE) only marks the CPU
>   cache dirty, and non-coherent DMA importers clean before starting DMA.
>   Persistent DRM/KMS imports then need a sync call on each submission.
> - Christian [3]: devices must access DMA-BUFs coherently with the CPU,
>   using begin/end_cpu_access() around CPU accesses. Importing a buffer
>   with dirty CPU caches onto a non-coherent device is intentionally
>   unsupported. Today cma_heap and system_heap sync all mapped
>   attachments inside begin/end_cpu_access().
> 
> On my Pi 500+ with a USB UVC camera (640x480 YUYV) and V3D on CMA
> DMA-BUFs:
> 
> - Without vb2 CPU sync, V3D reads stale data on 8/8 zero-copy frames.
> - With vb2 begin/end_cpu_access() on cma_heap, zero-copy V3D is clean
>   (0/8 stale). CPU capture takes 91 us/frame without a V3D import, and
>   144 us/frame when an idle V3D PRIME import is attached.
> - With a test heap that tracks CPU cache state and syncs imported BOs
>   at V3D job submission, zero-copy V3D stays clean (0/8 stale) and the
>   idle-V3D CPU read drops back to 89 us/frame.
> 
> Question to all: should I look at opt-in cache-state tracking in
> dma-buf (with a sync call before DMA submission), or keep
> begin/end_cpu_access() as is and handle CPU consumers via V4L2 cache
> hints?

A sync call before DMA operation is something we intentionally rejected.

Background is that exporters should export the buffers as they need/use it and not have specialized handling just to serve importers which would be not testable without the importer etc...

What we could do is to consistently use begin/end_cpu_access() and/or let exporters expose if their buffers might be dirty in the CPU cache so that importers can properly reject them.

Regards,
Christian.

> 
> [1] https://lore.kernel.org/r/20261021175900.GG15441@killaraus.ideasonboard.com/
> [2] https://lore.kernel.org/r/7e4c7707880e9092180d28484ecf674be29b40a0.camel@ndufresne.ca/
> [3] https://lore.kernel.org/r/1e798600-5a76-412a-959c-94313629baf4@amd.com/
> 
> Thanks,
> Karl