marfrit
5e68aec2e9
Replace the hand-rolled draft patches with the proper git-format-patch output. The new files apply cleanly via git am against unmodified Linux 6.12 mainline, verified by reset-and-apply roundtrip on /tmp/hantro-src (the local sparse checkout used during the chromium-fourier campaign). All kernel API calls also sanity-checked against the real include/linux/dma-fence.h and include/linux/dma-resv.h signatures: - dma_fence_init(fence, ops, lock, context, seqno) — argument list matches our call exactly - dma_resv_add_fence(obj, fence, usage) — DMA_RESV_USAGE_WRITE enum value confirmed present - dma_fence_signal, dma_fence_set_error, dma_fence_get, dma_fence_put, dma_fence_context_alloc — all present and correctly used - dma_resv_lock(obj, NULL), dma_resv_unlock — present, correctly paired README updated to reflect the post-verification status. Remaining gates before sending to linux-media are now: full-tree compile test (needs complete kernel checkout, hours of work), boot test on ohm (needs patched kernel build), and the runtime A/B (install patched kernel + uninstall kwin-fourier — chrome should still play 1080p30 because the fence is now real). Cover letter blurb filled in with the full motivation, test setup, and review-question list.
105 lines
4.4 KiB
Markdown
105 lines
4.4 KiB
Markdown
# 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.
|