From dcaa1f12e5448c49a4325010f9fd3326f0cd1a14 Mon Sep 17 00:00:00 2001 From: claude-noether Date: Wed, 6 May 2026 11:39:11 +0000 Subject: [PATCH] =?UTF-8?q?docs:=20clarify=20Rockchip=20silicon=20?= =?UTF-8?q?=E2=80=94=20PineTab2=20is=20RK3566,=20not=20RK3568?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Surfaced during iter7 Track F research: the campaign target hardware is Rockchip RK3566 silicon (PineTab2). The hantro driver attaches via the rockchip,rk3568-vpu DT compatible because the RK3566 silicon is close enough to RK3568 to share that variant. The proper RK3566 mainline driver target (rkvdec2 / vdpu346) has no kernel support yet — Christian Hewitt's patch series LKML 2025/12/26/206 is unmerged. Updates the two src/ comments that called the hardware "RK3568": - context.c: hantro-vpu device-init S_EXT_CTRLS comment now reads "via rockchip,rk3568-vpu DT compatible (covers RK3568 and RK3566 — PineTab2 silicon — since they're close enough)" - h264.c: DPB pic_num discussion ends "...never surfaced on PineTab2 (RK3566 via hantro/rk3568-vpu)" Not a correctness change. Compiles + decodes identically. The update matters for upstream submission accuracy (bootlin/Rockchip maintainers will care which silicon the campaign tested on). Co-Authored-By: Claude Opus 4.7 (1M context) --- src/context.c | 4 +++- src/h264.c | 2 +- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/src/context.c b/src/context.c index c2fa842..2eae439 100644 --- a/src/context.c +++ b/src/context.c @@ -131,7 +131,9 @@ VAStatus RequestCreateContext(VADriverContextP context, VAConfigID config_id, * device fd (request_fd=-1) before VIDIOC_STREAMON; per-request * controls (SPS/PPS/etc.) attached to a request_fd come later. * - * hantro-vpu (RK3568) accepts only DECODE_MODE_FRAME_BASED. + * hantro-vpu via rockchip,rk3568-vpu DT compatible (covers RK3568 + * and RK3566 — PineTab2 silicon — since they're close enough) + * accepts only DECODE_MODE_FRAME_BASED. * START_CODE_ANNEX_B preserves leading 0x00000001 in the slice * payload that h264.c assembles. Errors here are not fatal: not * every backing driver supports both controls (e.g. cedrus may diff --git a/src/h264.c b/src/h264.c index f95bc10..6202001 100644 --- a/src/h264.c +++ b/src/h264.c @@ -294,7 +294,7 @@ static void h264_fill_dpb(struct request_data *data, * one consumer that fails on that. Hantro doesn't read * pic_num at all (uses reference_ts for ref resolution), * which is why fourier's wrong value never surfaced on - * RK3568. + * PineTab2 (RK3566 via hantro/rk3568-vpu). */ if (entry->pic.flags & VA_PICTURE_H264_LONG_TERM_REFERENCE) { dpb->pic_num = entry->pic.frame_idx;