Re: [PATCH 2/4] media: videobuf2: add opt-in DMA-BUF CPU access

[Karl Mehltretter <kmehltretter@gmail.com>]

On Wed, Oct 21, 2026 at 05:03:19PM +0100, Nicolas Dufresne wrote:
> > I think the dma-buf API doesn't give us what we need. Cleaning the CPU
> > cache through end_cpu_access() when the producer is done writting to the
> > buffer is right in some use cases, but not in all of them. It assumes
> > that the next consumer will access the data through DMA, which isn't
> > always the case. What I think we need is to track the state of the
> > cache(s) in the dma_buf, and perform cache management operations
> > accordingly when needed. In the uvcvideo -> display use case for
> > instance, the dma_buf should track that the CPU cache is dirty when
> > finishing CPU access, and should be cleaned on the display side before
> > performing the DMA. In a use case where the producer would DMA to the
> > buffer, cache management would be skipped as the dma_buf would see that
> > the cache is not dirty.
> 
> I also second this as the only viable option. Its not only about uvcvideo, but
> any memory imported by a driver doing DMA (which is not also the exporter). That
> includes udmabuf usage. These days, cache artifacts are visible with Intel
> display controllers, and Intel mobile GPU drivers. Note that GStreamer properly
> signal CPU read/write using DMABuf sync ioctl.
> 
> For most Intel laptop user with GStreamer 1.28, these example produce artifacts
> on movement. To me, the solution is to track the cache state according to the
> access signalling (either userspace or driver), and let DMA user/consumer decide
> if a cache flush is needed. There is a obvious challenge in keeping this state
> coherent whenever there is multiple consumer, of if some broken application do
> concurrent write. Result for the last will always be undefined, but the dmabuf
> CPU cache state should not be undefined.
> 

For a persistently mapped attachment, where would the transition to
device access happen? 

dma_buf_map_attachment() may only run once, while the importer can
submit the buffer many times. Would this need a new per-attachment
operation before each submission, or can an existing event be used?

I tested that distinction with one persistent V3D attachment on my Pi
400 and Pi 500+:

- If end_cpu_access() only recorded dirty state, with no sync before
  submission, V3D read stale data in all 64 frames on both boards.

- Synchronizing the attachment immediately before submission produced
  64/64 matching frames on both boards.

This only covers V3D, but it seems that a dirty bit still needs a
device-side use event. Is that the model you had in mind?

Thanks,
Karl