# vb2 dma_resv release-fence — RFC patch series

A 3-patch RFC series that adds an opt-in dma_resv exclusive-fence
API to videobuf2, with hantro and rockchip-rga as the first two
drivers to opt in. Drafted as part of the
[fourier](https://github.com/marfrit/fourier) campaign — see the
top-level [`KWIN_PIVOT.md`](../../arch/chromium-fourier/KWIN_PIVOT.md)
for the discovery thread.

## Files

```
0000-cover-letter.patch
0001-media-videobuf2-add-dma_resv-release-fence-helper.patch
0002-media-hantro-attach-dma_resv-release-fence-at-buf_queue.patch
0003-media-rockchip-rga-attach-dma_resv-release-fence-at-buf_queue.patch
```

## What this fixes

vb2 producers historically don't propagate buffer-state-done into
the dmabuf's `dma_resv` exclusive fence. Userspace consumers that
import V4L2-produced dmabufs and try to do implicit synchronization
the spec-clean way (`poll(POLLIN)` on the dmabuf fd, or
`DMA_BUF_IOCTL_EXPORT_SYNC_FILE` for a sync_file) get either zero
fences or a stub fence from `dma_fence_get_stub()`. This is correct
by accident for the common case (clients call DQBUF before
importing) but represents a contract gap.

The opt-in API in patch 1 lets a driver populate a real fence at
QBUF time and have it signalled by vb2_buffer_done. Patches 2 and 3
demonstrate the call shape on hantro and rga (one line each in
their respective `buf_queue` callbacks).

## Status

**Patches apply cleanly to Linux 6.12 mainline via `git am`** —
verified against `/tmp/hantro-src` (sparse-checked-out v6.12 plus
linux-next master). All kernel API calls verified to match real
signatures in `include/linux/dma-fence.h` and
`include/linux/dma-resv.h`:

- `dma_fence_init(fence, ops, lock, context, seqno)` ✓
- `dma_resv_add_fence(obj, fence, usage)` ✓
- `DMA_RESV_USAGE_WRITE` enum present ✓
- `dma_fence_signal`, `dma_fence_set_error`, `dma_fence_get`,
  `dma_fence_put`, `dma_fence_context_alloc` ✓
- `dma_resv_lock(obj, NULL)`, `dma_resv_unlock` ✓

Remaining gates before sending to linux-media:

1. **Compile** — `make drivers/media/common/videobuf2/videobuf2-core.o
   drivers/media/platform/verisilicon/hantro_v4l2.o
   drivers/media/platform/rockchip/rga/rga-buf.o` against the kernel
   tree the patches will land on. Fix any drift in declarations or
   line numbers.
2. **Boot test on ohm** — install the patched kernel, verify hantro
   and rga still queue/dequeue buffers correctly (mpv `--vo=drm`
   smoke test, gstreamer rga pipeline smoke test).
3. **Validate the fence semantics** — install patched kernel, **also
   uninstall the kwin-fourier package** (so KWin's watchDmaBuf is
   active again), play 1080p30 H.264 in chromium-fourier under KDE
   Plasma 6.6.4 Wayland: should plays through end-to-end *without*
   the watchDmaBuf bypass, because the fence wait now waits on a
   real fence that signals when hantro completes the buffer.
4. **Capture timings** — `dma_buf_export_sync_file` round-trip
   latency before and after, on the same hardware. The patch
   should not regress; ideally the fence-add path is fast enough
   that compositor latency improves slightly (the wait now fires
   on real producer completion instead of a stub-resolved poll).

If 3 passes, the RFC has end-to-end validation backing the
submission. Send to linux-media:

```
git format-patch --cover-letter --to=linux-media@vger.kernel.org \
                 --cc='Hans Verkuil <hverkuil@xs4all.nl>' \
                 --cc='Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>' \
                 --cc='Mauro Carvalho Chehab <mchehab@kernel.org>' \
                 --cc='dri-devel@lists.freedesktop.org' \
                 -3 HEAD
```

## Open questions for upstream review

(Listed in the cover letter; copying here for convenience.)

- **Opt-in vs. auto-on**: should every CAPTURE queue auto-attach
  fences, or stay opt-in per-driver? Auto-on is more correct but
  forces every driver to be audited; opt-in is incremental and
  safer.
- **Signal point**: `vb2_buffer_done` is the latest moment the
  producer-write is guaranteed-complete. For drivers with async
  post-processing stages (image-processor pipelines) the producer
  fence might want to fire at an earlier point. Out of scope for
  this RFC; revisit when an actual driver complains.
- **DMA_RESV_USAGE_WRITE vs. older `dma_resv_set_excl_fence`**:
  matches dma-buf documentation for "this device produced a
  write." Sanity check welcome.

## License

Patches are GPL-2.0-only matching the kernel source. The cover
letter is informational.