On Thu, Oct 22, 2026 at 01:20:45AM +0100, Tomasz Figa wrote: > On Mon, Oct 19, 2026 at 4:14 PM Karl Mehltretter <[email protected]> > wrote: > > Add a queue flag to do so from buf_prepare() through buf_finish(). Use > > read access for output and write access for capture. Map imports > > bidirectionally because CPU and device access directions are opposite. > > Pass the mapping direction to attach_dmabuf() so USERPTR and MMAP keep > > the queue's normal direction. > > This isn't right. For the regular vb2 mem ops (dma-sg, dma-contig), a > buffer in the prepared state is expected to be ready for hardware > usage, meaning only the hardware can access it until the buffer is > finished. The vmalloc ops are special in a way that CPU is the > "hardware".
Agreed. vivid can select vb2_dma_contig_memops while patch 4 enables uses_cpu_access unconditionally. Automatic handling belongs in vb2_vmalloc_memops. Regular DMA memops need separate handling. > > Keep this opt-in because some vb2-vmalloc drivers pass buffers to > > hardware. End access in process context because DMA-BUF callbacks may > > sleep. > > That is at least unexpected, but also probably wrong (I haven't > checked all the drivers) - the vmalloc mem ops are expected to be used > by drivers that only access the buffer contents from the CPU. One current exception is AMD ISP4. It combines VB2_DMABUF with vb2_vmalloc_memops, imports and pins the DMA-BUF through amdgpu, and passes the resulting GPU address to ISP firmware. > Putting all the above together, what I think we need is: > 1) prepare/finish ops in vb2_vmalloc_memops to invoke the > dma_buf_begin/end_cpu_access() API if the buffer is backed by a > DMA-buf, > 2) some vb2 API for drivers using the regular (dma-) memops to invoke > the dma_buf_begin/end_cpu_access() API for them when they need to > perform some CPU accesses to the buffers - typically they would do > that in their vb2_ops::buf_prepare/finish callbacks, but definitelly > must not after the buffer is already prepared. > > It sounds like this series focuses on uvcvideo and vivid, which likely > means that 1) alone would be enough to fix the original problem. WDYT? 1) alone would cover the original vmalloc problem. But today it would also mark the ISP4 hardware interval as CPU access. The memops finish() callback may also run from vb2_buffer_done() in atomic context, while dma_buf_end_cpu_access() may sleep. The callbacks are void, so errors cannot be returned. Should ISP4 move to different memops, or should CPU access remain opt-in for vb2-vmalloc queues? Thanks, Karl
