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.
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 campaign — see the
top-level 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_WRITEenum 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:
- Compile —
make drivers/media/common/videobuf2/videobuf2-core.o drivers/media/platform/verisilicon/hantro_v4l2.o drivers/media/platform/rockchip/rga/rga-buf.oagainst the kernel tree the patches will land on. Fix any drift in declarations or line numbers. - Boot test on ohm — install the patched kernel, verify hantro
and rga still queue/dequeue buffers correctly (mpv
--vo=drmsmoke test, gstreamer rga pipeline smoke test). - 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.
- Capture timings —
dma_buf_export_sync_fileround-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_doneis 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.