From: Arun Iyengar via B4 Relay <devnull+aiyengar1990.gmail.com@kernel.org>
To: Nicolas Dufresne <nicolas.dufresne@collabora.com>,
Benjamin Gaignard <benjamin.gaignard@collabora.com>,
Philipp Zabel <p.zabel@pengutronix.de>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Heiko Stuebner <heiko@sntech.de>,
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>,
Hans Verkuil <hverkuil@kernel.org>,
Boris Brezillon <boris.brezillon@collabora.com>,
Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Cc: linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Sergei Khomenkov <shomenkow@gmail.com>,
Arun Iyengar <aiyengar1990@gmail.com>
Subject: [PATCH v2 6/7] media: verisilicon: Don't reset the encoder raw format while OUTPUT buffers exist
Date: Thu, 12 Nov 2026 08:31:28 +0000 [thread overview]
Message-ID: <20261112-hantro-jpeg-enc-fixes-v2-6-de03e643c75d@gmail.com> (raw)
In-Reply-To: <20261112-hantro-jpeg-enc-fixes-v2-0-de03e643c75d@gmail.com>
From: Arun Iyengar <aiyengar1990@gmail.com>
For an encoder, hantro_set_fmt_cap() allows S_FMT on the CAPTURE queue
while the OUTPUT queue has buffers as long as the coded pixel format and
size don't change, and then unconditionally resets the raw format through
hantro_reset_raw_fmt(). That helper sets ctx->vpu_src_fmt to the default
raw format before hantro_set_fmt_out() refuses the change with -EBUSY
(the OUTPUT queue is busy). hantro_set_fmt_cap() ignores that error, so
the ioctl succeeds but leaves the context inconsistent: ctx->src_fmt
still describes the negotiated raw format (e.g. NM12, two planes) while
ctx->vpu_src_fmt describes the default one (YM12, three planes).
The next job then programs the hardware with the wrong input format: on
the RK3588 VEPU121 JPEG encoder the third plane address is never written,
the encoder reads the V plane from IOVA 0 and the job ends in an IOMMU
page fault and a watchdog timeout. v4l2-ctl triggers this on every
--stream-mmap run, because it re-applies the CAPTURE format after the
OUTPUT queue has been set up:
rk_iommu fdba0800.iommu: Page fault at 0x0000000000000000 of type read
rk_iommu fdba0800.iommu: Page fault at 0x00000000000003c0 of type read
...
hantro_watchdog:208: frame processing timed out!
Skip the raw format reset when OUTPUT buffers exist: the coded format is
unchanged in that case, so the raw format stays valid, and the S_FMT is
accepted as the busy check intends. Also restore ctx->vpu_src_fmt in
hantro_reset_raw_fmt() when hantro_set_fmt_out() fails, so that no other
caller can leave the two descriptors out of sync.
The raw format has been reset under allocated OUTPUT buffers since the
encoder was added. Since commit 14b4bd01f8e5 ("media: verisilicon:
Additional fix for the crash when opening the driver") only the
descriptor is reset, which gives the mismatch described above.
Fixes: 775fec69008d ("media: add Rockchip VPU JPEG encoder driver")
Fixes: 14b4bd01f8e5 ("media: verisilicon: Additional fix for the crash when opening the driver")
Signed-off-by: Arun Iyengar <aiyengar1990@gmail.com>
---
drivers/media/platform/verisilicon/hantro_v4l2.c | 33 +++++++++++++++++++-----
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/media/platform/verisilicon/hantro_v4l2.c b/drivers/media/platform/verisilicon/hantro_v4l2.c
index 11bce0cdf4b3..a40abe2c459f 100644
--- a/drivers/media/platform/verisilicon/hantro_v4l2.c
+++ b/drivers/media/platform/verisilicon/hantro_v4l2.c
@@ -471,7 +471,7 @@ hantro_reset_encoded_fmt(struct hantro_ctx *ctx)
int
hantro_reset_raw_fmt(struct hantro_ctx *ctx, int bit_depth, bool need_postproc)
{
- const struct hantro_fmt *raw_vpu_fmt;
+ const struct hantro_fmt *raw_vpu_fmt, *old_vpu_src_fmt = NULL;
struct v4l2_pix_format_mplane raw_fmt, *encoded_fmt;
int ret;
@@ -481,6 +481,7 @@ hantro_reset_raw_fmt(struct hantro_ctx *ctx, int bit_depth, bool need_postproc)
if (ctx->is_encoder) {
encoded_fmt = &ctx->dst_fmt;
+ old_vpu_src_fmt = ctx->vpu_src_fmt;
ctx->vpu_src_fmt = raw_vpu_fmt;
} else {
encoded_fmt = &ctx->src_fmt;
@@ -497,6 +498,12 @@ hantro_reset_raw_fmt(struct hantro_ctx *ctx, int bit_depth, bool need_postproc)
if (!ret) {
ctx->bit_depth = bit_depth;
ctx->need_postproc = need_postproc;
+ } else if (ctx->is_encoder) {
+ /*
+ * hantro_set_fmt_out() refused the new raw format, so the
+ * OUTPUT format is unchanged: keep its descriptor in sync.
+ */
+ ctx->vpu_src_fmt = old_vpu_src_fmt;
}
return ret;
@@ -643,6 +650,7 @@ static int hantro_set_fmt_out(struct hantro_ctx *ctx,
static int hantro_set_fmt_cap(struct hantro_ctx *ctx,
struct v4l2_pix_format_mplane *pix_mp)
{
+ bool reset_raw_fmt = ctx->is_encoder;
int ret;
if (ctx->is_encoder) {
@@ -661,11 +669,22 @@ static int hantro_set_fmt_cap(struct hantro_ctx *ctx,
*/
peer_vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx,
V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE);
- if (vb2_is_busy(peer_vq) &&
- (pix_mp->pixelformat != ctx->dst_fmt.pixelformat ||
- pix_mp->height != ctx->dst_fmt.height ||
- pix_mp->width != ctx->dst_fmt.width))
- return -EBUSY;
+ if (vb2_is_busy(peer_vq)) {
+ if (pix_mp->pixelformat != ctx->dst_fmt.pixelformat ||
+ pix_mp->height != ctx->dst_fmt.height ||
+ pix_mp->width != ctx->dst_fmt.width)
+ return -EBUSY;
+
+ /*
+ * The coded format is unchanged, so the raw format
+ * stays valid. It couldn't be reset anyway while
+ * OUTPUT buffers exist (hantro_set_fmt_out() would
+ * refuse), and failing here after the coded format
+ * has been updated would leave the context
+ * inconsistent.
+ */
+ reset_raw_fmt = false;
+ }
}
ret = hantro_try_fmt(ctx, pix_mp, V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE);
@@ -687,7 +706,7 @@ static int hantro_set_fmt_cap(struct hantro_ctx *ctx,
* Note that hantro_reset_raw_fmt() also propagates size
* changes to the raw format.
*/
- if (ctx->is_encoder)
+ if (reset_raw_fmt)
hantro_reset_raw_fmt(ctx, HANTRO_DEFAULT_BIT_DEPTH, HANTRO_AUTO_POSTPROC);
/* Colorimetry information are always propagated. */
--
2.55.0
next prev parent reply other threads:[~2026-11-12 8:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 8:31 [PATCH v2 0/7] media: verisilicon: Fix the JPEG encoder format handling Arun Iyengar via B4 Relay
2026-11-12 8:31 ` [PATCH v2 1/7] media: verisilicon: Keep the encoder CAPTURE format while buffers exist Arun Iyengar via B4 Relay
2026-11-12 8:31 ` [PATCH v2 2/7] media: verisilicon: Enforce a minimum CAPTURE sizeimage for the encoder Arun Iyengar via B4 Relay
2026-11-12 8:31 ` [PATCH v2 3/7] media: verisilicon: Keep the encoder coded size in sync with OUTPUT Arun Iyengar via B4 Relay
2026-11-12 8:31 ` [PATCH v2 4/7] media: verisilicon: Refuse JPEG encode jobs with inconsistent geometry Arun Iyengar via B4 Relay
2026-11-12 8:31 ` [PATCH v2 5/7] media: verisilicon: Report fixed JPEG colorimetry on the encoder Arun Iyengar via B4 Relay
2026-11-12 8:31 ` Arun Iyengar via B4 Relay [this message]
2026-11-12 8:31 ` [PATCH v2 7/7] media: verisilicon: rockchip: Limit the JPEG encoder to 8176x8176 Arun Iyengar via B4 Relay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261112-hantro-jpeg-enc-fixes-v2-6-de03e643c75d@gmail.com \
--to=devnull+aiyengar1990.gmail.com@kernel.org \
--cc=aiyengar1990@gmail.com \
--cc=andrzej.p@collabora.com \
--cc=benjamin.gaignard@collabora.com \
--cc=boris.brezillon@collabora.com \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=heiko@sntech.de \
--cc=hverkuil@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mchehab@kernel.org \
--cc=nicolas.dufresne@collabora.com \
--cc=p.zabel@pengutronix.de \
--cc=shomenkow@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®