claude-noether
5a1ba37791
Phase 1 v1 claimed VP9 enablement was a < 100-line wiring patch
reusing legacy rkvdec_vp9_fmt_ops in vdpu381_coded_fmts[]. Janet
architect review (verdict AMEND) surfaced two BLOCKERs that overturn
the thesis:
A. vdpu381_variant.num_regs is unset (defaults 0); legacy VP9 path's
rkvdec_memcpy_toio writes MIN(sizeof, 0)=0 bytes. Zero MMIO config.
B. vdpu381 register layout is segmented across 5 distinct OFFSET_*
blocks (COMMON, CODEC_PARAMS, COMMON_ADDR, CODEC_ADDR, POC_HIGHBIT)
plus decode trigger at VDPU381_REG_DEC_E=0x028. Legacy VP9 writes
flat-from-base+0 and triggers via RKVDEC_REG_INTERRUPT=0x004 —
wrong register-block layout AND wrong trigger offset.
Plus Amendment C: BSP rkvdec2_irq checks BIT(1); mainline
vdpu381_irq_handler checks BIT(2). Same register (0x380), different
bit. VP9-set BIT(1) status would misclassify as ERROR.
Both blockers confirmed empirically by reading mainline rkvdec.c and
BSP mpp_rkvdec2.c source (rkvdec2_run dispatches via mpp_write_req
on req->offset, NOT a flat dump; trans_tbl_vp9d shares HEVC's
128..199 register-DMA range).
v2 architecture: new rkvdec-vdpu381-vp9.c backend (~600-800 lines)
+ extracted rkvdec-vp9-common.{c,h} for the SPEC layer (probability
tables, frame_ctx, segmap) + VP9 register-struct extensions in
rkvdec-vdpu381-regs.h. Reuses vdpu381_irq_handler, V4L2 controls,
RCB infrastructure, IOMMU path — all confirmed as codec-agnostic.
Sourcing the bit-packed register struct definitions from Rockchip
BSP MPP hal_vp9d_vdpu382.c (vdpu382 = sibling IP family).
Next: Phase 1 v2 → Janet re-review for sign-off before Phase 2 code.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
ampere-vp9-enablement
Stand-alone port + upstream-targeting work to enable VP9 hardware decode on Rockchip RK3588's rkvdec (vdpu381 register layout).
Status (2026-05-17 ~01:00)
Upstream RK3588 mainline rkvdec (Casanova v7.0 series, landed in Linux 7.0) supports H.264 + HEVC only. VP9 is on Collabora's stated roadmap but no WIP series has been posted to linux-media as of this campaign open. The legacy rkvdec-vp9.c (RK3399 / vdpu341 hardware) is feature-complete at 1042 lines but its register-config logic does not translate directly to vdpu381.
This campaign:
- Ports VP9 enablement to vdpu381 register layout (new file
rkvdec-vdpu381-vp9.c) - Registers VP9 V4L2 controls in
vdpu38x_vp9_ctrl_descs[] - Adds VP9 fmt to
vdpu381_coded_fmts[]with the new ops - Verifies bit-perfect HW vs SW decode (per feedback_compare_hw_against_sw_reference)
- Proposes upstream via linux-media
Sibling campaign: ampere-kernel-decoders closed at HEVC bit-perfect (kernel-agent#14 + #15 are the prerequisite kernel fixes).
Scope (out of)
- VP9 on RK3399 (works via legacy
rkvdec-vp9.calready in mainline) - VP9 on hantro (hantro decoder on RK3588 doesn't expose VP9; this campaign targets rkvdec)
- AV1 on RK3588 (separate work; AV1 is on hantro fdc70000 already + per Collabora)
- VP8 (already works via hantro)
- HEVC (closed in ampere-kernel-decoders)
Process
8-phase loop (per ~/.claude/CLAUDE.md). All commits via claude-noether identity. Patches will be RFC-quality and routed via kernel-agent once ready.