Rockchip BSP inspection (mpp_rkvdec2.c, soc.cmake, vp9d/CMakeLists.txt)
overturns the initial premise. The same physical rkvdec IP on RK3588
accepts two register-protocol dialects within its 0x400 MMIO window:
- vdpu381 dialect (Casanova mainline naming) — H.264 + HEVC
- vdpu34x dialect (Rockchip legacy naming) — VP9 + AVS2
BSP rkvdec_rk3588_data uses rkvdec_v2_hw_info + rkvdec_v2_trans, the
same dispatch tables as RK356X. MPP userspace builds the vdpu34x VP9
backend for RK3588 because no vdpu381 VP9 backend exists; it isn't
needed — the existing vdpu34x register layout drives this hardware.
Implication: mainline rkvdec_vp9_fmt_ops (vdpu34x layout, written for
RK3399) can drive RK3588 rkvdec hardware as-is. VP9 enablement is a
< 100-line wiring patch (third entry in vdpu381_coded_fmts[] + maybe a
codec-aware IRQ split), not a 1000+ line backend port.
Open questions revised; risk register tightened.
Phase 1 starts by reading BSP rkvdec_rk3588_hw_ops IRQ + power-on
routines to resolve O2/O3 (codec-aware dispatch needed? mode-switch
register?) and BSP vp9d_vdpu34x.c for max-resolution + RCB usage.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Open ampere-vp9-enablement to enable VP9 hardware decode on RK3588 ampere
(rkvdec / vdpu381 register layout). Sibling to ampere-kernel-decoders
(closed at HEVC bit-perfect 2026-05-17 ~00:42).
Phase 0 substrate locked: upstream status (Collabora roadmap, no series
posted), legacy code reference (rkvdec-vp9.c 1042 lines, vdpu341),
vdpu381 pattern reference (rkvdec-vdpu381-hevc.c, struct-based regs +
common-file split), work-plan outline, open questions (chiefly: where
is the vdpu381 VP9 register layout documented), risk register.
Phase 1 (architectural plan + Sonnet review) next session.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
claude-noether