From: Sergei Khomenkov via B4 Relay <devnull+shomenkow.gmail.com@kernel.org>
To: Nicolas Dufresne <nicolas.dufresne@collabora.com>,
Benjamin Gaignard <benjamin.gaignard@collabora.com>,
Philipp Zabel <p.zabel@pengutronix.de>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
Hans Verkuil <hverkuil@kernel.org>,
Heiko Stuebner <heiko@sntech.de>,
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>,
Chen-Yu Tsai <wenst@chromium.org>,
Hugues Fruchet <hugues.fruchet@foss.st.com>,
linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
Sergei Khomenkov <shomenkow@gmail.com>
Subject: [PATCH v2 2/3] media: verisilicon: program the H1 JPEG stream limit in 64-bit words
Date: Tue, 10 Nov 2026 15:41:45 +0300 [thread overview]
Message-ID: <20261110-hantro-buflimit-v2-2-ff7790def9fc@gmail.com> (raw)
In-Reply-To: <20261110-hantro-buflimit-v2-0-ff7790def9fc@gmail.com>
From: Sergei Khomenkov <shomenkow@gmail.com>
H1_REG_STR_BUF_LIMIT counts 64-bit words, but the driver writes the room
left in the CAPTURE plane in bytes. A stream that does not fit, such as
a quality 100 frame of noise in a default-sized buffer, is then written
past the end of the plane, up to eight times its size.
Write the limit in 64-bit words, rounded down to whole 64-byte bursts:
the encoder finishes a burst it has started, so an unrounded limit lets
it write up to 56 bytes past it.
Found with an LLM coding assistant while porting mainline Linux to a
Rockchip RK3026 board; the assistant also drafted this change. Tested
on that board: overflowing frames now stop at the programmed limit
without writing past the plane, and frames that fit are byte for byte
the same as before. Not tested on other SoCs, including the STM32MP25,
which shares this code.
Fixes: 775fec69008d ("media: add Rockchip VPU JPEG encoder driver")
Cc: stable@vger.kernel.org
Signed-off-by: Sergei Khomenkov <shomenkow@gmail.com>
---
drivers/media/platform/verisilicon/hantro_h1_jpeg_enc.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/verisilicon/hantro_h1_jpeg_enc.c b/drivers/media/platform/verisilicon/hantro_h1_jpeg_enc.c
index 86cc1a07026f..665a87e9fe92 100644
--- a/drivers/media/platform/verisilicon/hantro_h1_jpeg_enc.c
+++ b/drivers/media/platform/verisilicon/hantro_h1_jpeg_enc.c
@@ -55,7 +55,12 @@ static void hantro_h1_jpeg_enc_set_buffers(struct hantro_dev *vpu,
vepu_write_relaxed(vpu, vb2_dma_contig_plane_dma_addr(dst_buf, 0) +
ctx->vpu_dst_fmt->header_size,
H1_REG_ADDR_OUTPUT_STREAM);
- vepu_write_relaxed(vpu, size_left, H1_REG_STR_BUF_LIMIT);
+ /*
+ * The limit is in 64-bit words. The encoder finishes a 64-byte burst
+ * it has started (measured on the RK3026), so give it whole bursts.
+ */
+ vepu_write_relaxed(vpu, round_down(size_left, 64) / 8,
+ H1_REG_STR_BUF_LIMIT);
if (pix_fmt->num_planes == 1) {
src[0] = vb2_dma_contig_plane_dma_addr(src_buf, 0);
--
2.53.0
next prev parent reply other threads:[~2026-11-10 12:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 12:41 [PATCH v2 0/3] media: verisilicon: fix VEPU1 JPEG encoder writes past the CAPTURE buffer Sergei Khomenkov via B4 Relay
2026-11-10 12:41 ` [PATCH v2 1/3] media: verisilicon: stop the VEPU1 JPEG encoder after an unfinished frame Sergei Khomenkov via B4 Relay
2026-11-10 12:41 ` Sergei Khomenkov via B4 Relay [this message]
2026-11-10 12:41 ` [PATCH v2 3/3] media: verisilicon: leave room for the JPEG header and one stream burst Sergei Khomenkov 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=20261110-hantro-buflimit-v2-2-ff7790def9fc@gmail.com \
--to=devnull+shomenkow.gmail.com@kernel.org \
--cc=benjamin.gaignard@collabora.com \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=heiko@sntech.de \
--cc=hugues.fruchet@foss.st.com \
--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=linux-stm32@st-md-mailman.stormreply.com \
--cc=mchehab@kernel.org \
--cc=nicolas.dufresne@collabora.com \
--cc=p.zabel@pengutronix.de \
--cc=shomenkow@gmail.com \
--cc=stable@vger.kernel.org \
--cc=wenst@chromium.org \
/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®