Janet structural review + 4 more diagnostic iters (7-10) revealed:
- HW reads reg197_cabactbl_base, reg161/163, and prob bases
unconditionally for VP9 (BSP works because its kernel skips fd=0;
mainline writes raw IOVAs so 0 = IOMMU fault)
- Prob content does NOT matter for stall (zero-byte scratch and
legacy-format priv_tbl.probs hang identically)
- Struct size gaps (60-byte unwritten tail in vp9_param) match HEVC's
layout and aren't the cause
Final hypothesis space:
1. BSP-specific kernel init we're missing (cache config / AXI QoS)
2. vdpu381 mode-2 reserved but never validated by Casanova
3. Prob buffer needs VP9-specific INITIALIZATION (not just any pointer)
All 3 require structural rework, not register tuning. Per Janet
PIVOT verdict, recommend Option A: pivot to AV1 on vdpu383 (Casanova
ships it complete in v7.0; 1-2 days port).
Branch boltzmann:~/src/linux-rockchip:vp9-enablement-iter1 head
3d7ffae30626 — 7 commits, 1620 LoC, compiles clean, VP9F enumerates
on /dev/video1, HW does not decode.
Ampere recovery to sibling-campaign close:
sudo cp ~/vp9-iter1-backup/rockchip-vdec.ko.sibling-campaign-close \
/lib/modules/$(uname -r)/kernel/drivers/media/platform/rockchip/rkvdec/
sudo depmod -a && sudo modprobe -r rockchip-vdec && sudo modprobe rockchip-vdec
Campaign closes at "structural impossibility identified", with
substantial substrate preserved for future Collabora coordination or
RE work.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Module loads + format enumerates (kernel-side wiring works) but every
VP9 decode attempt stalls the HW: STA_INT=0x23 (IRQ_RAW + TIMEOUT) when
HW timeout enabled; NO IRQ at all when timeout disabled (genuine stall).
6 iterations of register-tuning all failed identically. Hypothesis
space narrowed to 3 structural-level possibilities:
1. Probability buffer format mismatch (legacy struct rkvdec_vp9_probs
vs BSP hal_vp9d_prob_default format)
2. Missing kernel-side init (cache config, SRAM/QoS, AXI setup that
BSP mpp_rkvdec2 does but mainline HEVC happens not to need)
3. vdpu381 register layout doesn't fully expose VP9 control surface
(BSP MPP may rely on mpp_dev_set_reg_offset translations we don't
replicate)
Recommended next path: Sonnet/Janet architect review BEFORE more
iteration. The 6 single-bit tuning rounds established that no bit-flip
fix is sufficient — structural rethink required.
Sibling-campaign close state (HEVC bit-perfect) recoverable on ampere
via backup at ~/vp9-iter1-backup/rockchip-vdec.ko.sibling-campaign-close
+ depmod cycle.
Phase 0-2.1 work preserved at boltzmann:~/src/linux-rockchip:
vp9-enablement-iter1 (6 commits, 1517 LoC). Format enumeration on
/dev/video1 confirms kernel-side wiring is correct.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Commit 63c4db0095ca on boltzmann vp9-enablement-iter1 branch adds the
full register-packing path: RCB addresses, block clock-gating defaults,
frame-area timeout threshold (with rkvdec_schedule_watchdog), 8-segment
packing helper, ref/mode-deltas bit-packing into 28/14-bit combined
fields, and first-cut probability storage aliasing.
Branch is now at 4 commits, 1390 LoC across 4 files. Module compiles
clean against 7.0.0-rc3 ARM64 kernel.
What remains potentially-needed for first-light is in reg103_frame_flags
(prob_update_en, ref/mode/single/comp refresh enables, etc.) — currently
zero-init; will tune in Phase 6 if byte-compare diverges from SW.
Phase 3 (hardware install + first decode) is the natural inflection
point. Module artifact is at boltzmann:~/src/linux-rockchip/drivers/media
/platform/rockchip/rkvdec/rockchip-vdec.ko, ready to install on ampere
after backing up the current sibling-campaign module.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Followup to 3834ba0. Two push attempts to gitea
(claude-noether/linux-rk3588-marfrit:vp9-enablement-iter1) failed with
"send-pack: unexpected disconnect while reading sideband packet".
Likely cause: the branch base linux-rk3588-marfrit on boltzmann is
ahead of gitea remote and the resulting pack is too large to push in
one shot under current ssh stability.
Workaround for next session:
1. cd ~/src/linux-rockchip on boltzmann
2. git push gitea linux-rk3588-marfrit (sync the base first)
3. git push gitea vp9-enablement-iter1 (then push the campaign branch)
Or use --push.optionspack to chunk; or use HTTPS+token if SSH stays
flaky.
Commits remain durable on boltzmann disk (~/src/linux-rockchip,
branch vp9-enablement-iter1, head 71cc0d96d212).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The translation guide for porting rkvdec_vp9_run and its config_*
helpers from the flat vdpu34x register layout to the segmented vdpu381
layout. Each row maps a legacy field to its new location across the
4 segments (common, vp9_param, common_addr, vp9_addr).
Key semantic deltas captured:
- reg02.dec_mode → reg009_dec_mode.dec_mode (VDPU381_MODE_VP9=2)
- Per-ref indexed arrays (reg17_19[i], reg29_31[i], reg37_39[i],
reg48_50[i]) become separate per-frame-slot registers
(last/golden/altref triplets) in vdpu381
- Decode trigger moves from RKVDEC_REG_INTERRUPT=0x004 +
RKVDEC_INTERRUPT_DEC_E mask to VDPU381_REG_DEC_E=0x028 +
VDPU381_DEC_E_BIT (single bit)
- reg09.yuv_virstride dropped (legacy-only convenience field)
- reg51.lastref_yuv_virstride dropped (not in vdpu381 layout)
- NEW fields surfaced: reg103_frame_flags (intra_only, prob_update_en,
refresh_en, allow_high_precision_mv, interp_filter_switch_en),
reg064_cprheader.cprheader_offset, reg105.count_update_en
Also captures 5 open questions for the next code-writing session
(prob-index rotation, delta_prob_base aliasing, RCB integration,
timeout threshold sizing).
This document IS the load-bearing artifact for the Phase 2 backend
implementation. The .c file translation walks this table line-by-line.
Companion to commit 47431635801d (regs header VP9 struct definitions).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Janet AMEND-cycle re-review of v2 returned 2 surgical corrections:
A. OFFSET_POC_HIGHBIT_REGS is HEVC/H.264 only — POC isn't a VP9
concept. rkvdec-vdpu381-vp9.c writes 4 segments (COMMON,
CODEC_PARAMS, COMMON_ADDR, CODEC_ADDR), not 5. Confirmed via BSP
hal_vp9d_vdpu382.c — no poc_highbit reference anywhere in VP9
path.
B. Common-file split narrowed: only spec-computation functions
(probability init, segmap state, entropy update) move into a
rkvdec-vp9-common.h header as static-inline helpers. The
register-writing functions (config_seg_registers,
config_ref_registers, config_registers) STAY in legacy
rkvdec-vp9.c — they touch the legacy flat struct rkvdec_regs
and can't share with the new vdpu381 struct without abstracting
the register backend (over-engineering). The new backend
rewrites these against the vdpu381 struct.
Bonus implementation hint: VDPU381_MODE_VP9=2 is already defined in
rkvdec-vdpu381-regs.h:22 — Casanova's v7.0 series had VP9 in mind
from the start, just didn't ship a backend.
RCB sizing tuning deferred to Phase 6 (vp9d_refine_rcb_size formula
from BSP).
With both amendments applied, Janet's verdict carry-forward is
PROCEED. Phase 2 implementation begins next session.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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>
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