Files
marfrit-packages/kernel/vb2-dma-resv-rfc/0002-media-hantro-attach-dma_resv-release-fence-at-buf_qu.patch
marfrit 5e68aec2e9 kernel/vb2-dma-resv-rfc: regenerate via git format-patch + verify
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.
2026-04-28 19:29:05 +00:00

57 lines
2.3 KiB
Diff

From 91522b562665b94607337a3f30d1586f818d9387 Mon Sep 17 00:00:00 2001
From: Markus Fritsche <mfritsche@reauktion.de>
Date: Tue, 28 Apr 2026 19:23:50 +0000
Subject: [PATCH 2/3] media: hantro: attach dma_resv release fence at buf_queue
Opt the hantro driver into the new vb2 release-fence helper.
When userspace QBUFs a buffer to hantro, the buffer is added to the
driver's m2m queue via v4l2_m2m_buf_queue. We additionally call
vb2_buffer_attach_release_fence() so each plane's dmabuf->resv
gets a real producer fence attached. The fence is signalled by
vb2_buffer_done when hantro completes the decode (via
v4l2_m2m_buf_done_and_job_finish in hantro_drv.c, which converges
on vb2_buffer_done).
Wayland compositors (and any other userspace) that import hantro
CAPTURE buffers and wait on the dmabuf's implicit-sync fence now
wait on a real fence representing the producer's actual completion,
not a stub. Validated end-to-end on PineTab2 (RK3566 / Mali-G52 /
mainline 6.19 with this series backported) playing 1080p30 H.264 in
chromium under stock KDE Plasma 6.6.4 Wayland: KWin's
Transaction::watchDmaBuf wait completes correctly the moment
hantro's IRQ fires, instead of falling back to a stub-resolved
poll.
Signed-off-by: Markus Fritsche <mfritsche@reauktion.de>
---
drivers/media/platform/verisilicon/hantro_v4l2.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/media/platform/verisilicon/hantro_v4l2.c b/drivers/media/platform/verisilicon/hantro_v4l2.c
index 62d3962c1..e95a3433a 100644
--- a/drivers/media/platform/verisilicon/hantro_v4l2.c
+++ b/drivers/media/platform/verisilicon/hantro_v4l2.c
@@ -877,6 +877,18 @@ static void hantro_buf_queue(struct vb2_buffer *vb)
}
v4l2_m2m_buf_queue(ctx->fh.m2m_ctx, vbuf);
+
+ /*
+ * Opt in to vb2's dma_resv release-fence path. Userspace
+ * consumers that imported this buffer's dmabuf and wait on
+ * its implicit-sync fence (poll(POLLIN) or
+ * DMA_BUF_IOCTL_EXPORT_SYNC_FILE) get a real producer fence
+ * representing this device's completion, instead of the stub
+ * fence dma_buf_export_sync_file substitutes when dma_resv
+ * is empty. Best-effort: a fence-allocation failure means we
+ * lose implicit-sync precision, no functional regression.
+ */
+ (void)vb2_buffer_attach_release_fence(vb);
}
static bool hantro_vq_is_coded(struct vb2_queue *q)
--
2.47.3