mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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>,
	 Hugues Fruchet <hugues.fruchet@foss.st.com>,
	 Heiko Stuebner <heiko@sntech.de>,
	linux-media@vger.kernel.org,  linux-rockchip@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	 linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	 Sergei Khomenkov <shomenkow@gmail.com>
Subject: [PATCH] media: verisilicon: postproc: fix the G1 input height extension
Date: Wed, 04 Nov 2026 14:27:00 +0300	[thread overview]
Message-ID: <20261104-b4-hantro-pp-v1-1-1d75e9b225f8@gmail.com> (raw)

From: Sergei Khomenkov <shomenkow@gmail.com>

The G1 post-processor takes its input size in macroblocks: the low
bits in swreg72, the high bits in swreg92 (bits 28:26 for bits 11:9
of the width, bits 31:29 for bits 10:8 of the height). This is the
VDPU1 layout in Rockchip's MPP library, whose JPEG decoder writes the
height extension as ((height / 16) & 0x700) >> 8.

hantro_postproc_g1_enable() computes the width extension that way but
writes the height extension as MB_HEIGHT(height >> 8), shifting lines
instead of macroblocks. Every input of 256 to 4080 lines gets an
extension of 1 instead of 0, so the post-processor is told it has 256
more macroblock rows than it has: 286 instead of 30 for 480 lines,
301 instead of 45 for 720 and 324 instead of 68 for 1080. Inputs
below 256 lines are not affected.

Shift the macroblock count, as is done for the width.

The problem was 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 (G1, ID 0x6731), decoding H.264
(640x480, 854x480, 1280x720) and VP8 (640x480, 1280x720) to YUYV
through the post-processor, 241 frames, against a software conversion
of the decoder's NV12 output. Without this change only the 4 VP8 key
frames match: a few pixels at the bottom left of the last macroblock
row differ from run to run, and VP8 inter frames propagate them. With
it all 241 frames match. 320x240 is correct either way.

Fixes: 3f6702e1be8a ("media: verisilicon: postproc: 4K support")
Cc: stable@vger.kernel.org
Signed-off-by: Sergei Khomenkov <shomenkow@gmail.com>
---
 drivers/media/platform/verisilicon/hantro_postproc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/verisilicon/hantro_postproc.c b/drivers/media/platform/verisilicon/hantro_postproc.c
index e94d1ba5ef10..ecc6b3137eb0 100644
--- a/drivers/media/platform/verisilicon/hantro_postproc.c
+++ b/drivers/media/platform/verisilicon/hantro_postproc.c
@@ -106,7 +106,7 @@ static void hantro_postproc_g1_enable(struct hantro_ctx *ctx)
 	HANTRO_PP_REG_WRITE(vpu, orig_width, MB_WIDTH(ctx->dst_fmt.width));
 	HANTRO_PP_REG_WRITE(vpu, display_width, ctx->dst_fmt.width);
 	HANTRO_PP_REG_WRITE(vpu, input_width_ext, MB_WIDTH(ctx->dst_fmt.width) >> 9);
-	HANTRO_PP_REG_WRITE(vpu, input_height_ext, MB_HEIGHT(ctx->dst_fmt.height >> 8));
+	HANTRO_PP_REG_WRITE(vpu, input_height_ext, MB_HEIGHT(ctx->dst_fmt.height) >> 8);
 }
 
 static int down_scale_factor(struct hantro_ctx *ctx)

---
base-commit: 27285b099fbc5cb2ae3aef20f3bbd7b3c88b3005
change-id: 20261104-b4-hantro-pp-1ce1b6891463

Best regards,
-- 
Sergei Khomenkov <shomenkow@gmail.com>



             reply	other threads:[~2026-11-04 11:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-04 11:27 Sergei Khomenkov via B4 Relay [this message]
2026-11-04 13:34 ` Nicolas Dufresne

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=20261104-b4-hantro-pp-v1-1-1d75e9b225f8@gmail.com \
    --to=devnull+shomenkow.gmail.com@kernel.org \
    --cc=benjamin.gaignard@collabora.com \
    --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=mchehab@kernel.org \
    --cc=nicolas.dufresne@collabora.com \
    --cc=p.zabel@pengutronix.de \
    --cc=shomenkow@gmail.com \
    --cc=stable@vger.kernel.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®