marfrit/libva-multiplanar
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: clarify Rockchip silicon across operative docs (RK3566)

Browse Source 
PineTab2 is Rockchip RK3566 silicon, not RK3568. The hantro driver
attaches via the rockchip,rk3568-vpu DT compatible because RK3566/
RK3568 silicon is close enough 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.

Updated operative docs to use the consistent form:
"PineTab2 (Rockchip RK3566 silicon; hantro driver via the
rockchip,rk3568-vpu DT compatible)" or shorter variants.

Files updated:
- README.md (campaign top-level): TL;DR, deliverable, KWin link,
  hardware target, hardware listing
- firefox-fourier/README.md: tested-on line
- phase8_iteration7_close.md: hardware carry
- phase8_iteration6_close.md: hardware carry, MPEG-2 drop
  rationale
- phase0_findings_iter7.md: predecessor summary, fourier-fresnel
  description, hardware carry
- phase2_iter7_situation.md: msync hypothesis hardware reference

Historical iter1-iter5 phase docs left as-is — they're snapshots
of what the campaign believed at the time. The canonical source
for the silicon-ID correction is track_F_research_2026-05-06.md
(commit 358801b).

Not a correctness change. The campaign's empirical evidence is
unaffected — the hantro/rk3568-vpu driver path that we exercised
was always the actual decode path on PineTab2 silicon.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude (noether)
2026-05-06 11:39:28 +00:00
parent 358801be06
commit ec769a9687
6 changed files with 15 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files
phase8_iteration6_close.md
+2 -2
View File
@@ -40,7 +40,7 @@ Closes GREEN with a single architectural fix.
## State that carries to iter7 (or campaign close)
- **Hardware**: ohm RK3568 hantro G1/G2, kernel 6.19.10. Access: `ohm` (LAN) — VPN currently flaky.
- **Hardware**: ohm PineTab2 (Rockchip RK3566 silicon; hantro driver via `rockchip,rk3568-vpu` DT compatible), kernel 6.19.10. Access: `ohm` (LAN) — VPN currently flaky.
- **Userspace**: firefox 150.0.1-1.1 (iter5 amendment), libva 2.23.0, mesa 26.0.5, libdrm 2.4.131, mpv 0.41.0-3.
- **Driver installed**: `/usr/lib/dri/v4l2_request_drv_video.so` sha256 `ebe396d55104dbfedfa1065232d7f1959c519b4afe6fe33f46c1b9af13465ed6` (iter6-end, REINIT discipline + pool=16).
- **Test fixture**: bbb_1080p30_h264.mp4 sha256 `dcf8a7170fbd...`.
@@ -78,7 +78,7 @@ Outstanding for upstream-readiness:
- Slot-leak error recovery (iter6 carry)
- Probe-pattern test harness for cap_pool race (iter5 sonnet C4 / iter6 candidate A — NOW EXERCISED organically by YT's resolution renegotiations, but a synthetic harness would anchor the claim)
iter1 lock's "H.264 first; MPEG-2 next" backlog item is dropped 2026-05-06: MPEG-2 SD/HD decodes trivially in CPU on RK3568's A55 cluster (well under one core), so the campaign's user audience doesn't need MPEG-2 HW path. If an upstream reviewer asks, the answer is "H.264-only by design — CPU handles MPEG-2 fine on this hardware."
iter1 lock's "H.264 first; MPEG-2 next" backlog item is dropped 2026-05-06: MPEG-2 SD/HD decodes trivially in CPU on PineTab2's A55 cluster (well under one core), so the campaign's user audience doesn't need MPEG-2 HW path. If an upstream reviewer asks, the answer is "H.264-only by design — CPU handles MPEG-2 fine on this hardware."
Per `feedback_no_upstream.md`, no PR/MR happens without explicit operator instruction.