kernel/vb2-dma-resv-rfc: 3-patch RFC series draft

Drafted but not yet compile-tested or runtime-validated. Draft
target: vb2 grows an opt-in dma_resv release-fence API; hantro and
rockchip-rga opt in as the demonstration drivers.

Series structure:
- 0000-cover-letter.patch  — context, motivation, validation results
- 0001-media-videobuf2-add-dma_resv-release-fence-helper.patch
    Adds vb2_buffer_attach_release_fence() that drivers call from
    their buf_queue callback. Stores the fence on vb->release_fence;
    vb2_buffer_done signals + puts. Per-queue fence context allocated
    at vb2_core_queue_init.
- 0002-media-hantro-attach-dma_resv-release-fence-at-buf_queue.patch
    Single call in hantro_buf_queue. ~5 lines.
- 0003-media-rockchip-rga-attach-dma_resv-release-fence-at-buf_queue.patch
    Same shape in rga_buf_queue. ~5 lines.

Pre-flight before sending to linux-media (per kernel/README.md):
1. Compile the touched files against the kernel tree the patches
   will land on (linux-next master as of 2026-04-28 was the source
   of truth used for context-line generation).
2. Boot-test on ohm, smoke-test hantro + rga buffer flows.
3. Validate the fence semantics: install patched kernel, uninstall
   kwin-fourier so KWin's watchDmaBuf is active, play 1080p30 H.264
   under KDE Plasma — should plays through without the bypass
   because the fence is now real.
4. Capture before/after dma_buf_export_sync_file timings.
5. Send via git format-patch --cover-letter to linux-media@,
   CC dri-devel@ and the relevant maintainers.

This series is the kernel-correct fix for the architectural hole
that the chromium-fourier campaign's kwin-fourier package is
papering over. With this kernel side upstream, kwin-fourier
becomes either redundant (if KWin's existing wait works correctly)
or rewritten as a poll-fd-direct optimization.

kernel/vb2-dma-resv-rfc/README.md

@@ -0,0 +1,94 @@
+# 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 drafted but **not yet applied / compile-tested / runtime-
+tested.** They're written against linux-next master as of
+2026-04-28 (sparse-checked-out at `/tmp/hantro-src` during the
+chromium-fourier campaign on ohm). Pre-flight before sending:
+
+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.