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

[Karl Mehltretter]

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?

[1] https://lore.kernel.org/r/20261021175900.GG15441@xxxxxxxxxxxxxxxxxxxxxxxxxx/
[2] https://lore.kernel.org/r/7e4c7707880e9092180d28484ecf674be29b40a0.camel@xxxxxxxxxxxx/
[3] https://lore.kernel.org/r/1e798600-5a76-412a-959c-94313629baf4@xxxxxxx/

Thanks,
Karl