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@ndu... [3] https://lore.kernel.org/r/1e798600-5a76-412a-959c-94313629baf4@amd.com/

Thanks, Karl