# patches/driver/media/

Scope-tagged kernel-agent patches that touch `drivers/media/` — third-party
video-codec enablement work that hasn't reached linux-media patchwork as
formal series yet, but is empirically known to work on our test hardware.

## 0001..0003 — Sarma's VP9 enablement on VDPU381 (RK3588 rkvdec)

Three patches from `D.V.A.B. Sarma <vdarbha0473@gmail.com>` adding VP9
decode support to the VDPU381 variant of rkvdec (the RK3588 generation).

| # | Subject | LOC | What |
|---|---------|----:|------|
| 0001 | rkvdec/vp9: rename get_ref_buf to get_ref_buf_vp9 | 10 | rename existing helper to avoid namespace collision with the upcoming HEVC equivalent |
| 0002 | rkvdec: move vp9 functions to common file | 172 | extract VP9 plumbing into `rkvdec-vp9-common.{c,h}` so VDPU381 can share with the older RK3399 backend |
| 0003 | rkvdec: add VP9 support for VDPU381 variant | 1303 | the actual VDPU381 VP9 backend — register defs + `rkvdec-vdpu381-vp9.c` + glue |

Combined: ~1500 LOC, 5 new files in `drivers/media/platform/rockchip/rkvdec/`.

### Upstream provenance

- Author maintains the work at https://github.com/dvab-sarma/android_kernel_rk_opi
  branch `add-rkvdec-vdpu381-vp9-v8`.
- Collabora's blog post on RK3588/RK3576 video decoder mainline merge cites
  the work but notes "v1 series needs to be sent for review soon" —
  i.e. not yet on linux-media patchwork, no upstream timeline.
- Casanova's VDPU381+VDPU383 H.264/HEVC base (which these patches sit on top
  of) IS in mainline 7.0 release.
- Patches do NOT modify any of our scope-tagged board / module / soc /
  subsystem code paths — purely additive to the upstream rkvdec subdirectory.

### Tested on

- Author: Orange Pi 5 Pro board (RK3588), AOSP 16 + FFMPEG, Profile 0 + Profile 2
- Our fleet: build verified clean on `ampere` (CoolPi CM5 GenBook, RK3588)
  2026-05-18 with KERNELRELEASE `7.0.0-rc3-vp9-test+` (base = running
  `7.0.0-rc3-devices+` config + LOCALVERSION change + these 3 patches +
  the pre-existing issue14 vb2-resv local mods). Full kernel image
  + DTB + modules + initramfs land at `/boot/firmware/*-7.0.0-rc3-vp9-test+`
  and `/lib/modules/7.0.0-rc3-vp9-test+`. New extlinux label `arch_vp9_test`
  added without touching default `arch_devices`. End-to-end VP9 decode
  validation requires booting into `arch_vp9_test` (pending operator
  confirmation, then `v4l2-ctl -d /dev/video1 --list-formats-out` should
  list `VP9F` alongside `S265` + `S264`).

### Apply order

Strict — 0001 → 0002 → 0003. 0003 depends on the common-file refactor
from 0002, which depends on the helper rename in 0001.

### Removal criteria

Drop these patches when:
- Sarma sends a v1 series to linux-media and it lands upstream — adopt
  the upstream version at the next baseline bump, OR
- Collabora produces an alternative VP9 enablement on their own
  hardware-enablement/rockchip-3588 GitLab tree — prefer that lineage
  (more likely to land cleanly upstream).

### How to use in a kernel-agent build

If `fleet/ampere.yaml` is bumped to include VP9 (currently scope-out per
the manifest preamble — "Asks #2 (VP9 enablement on RK3588 rkvdec) and
#3 (AV1 dec integration) from issue #6 are NOT addressed in this
manifest — tracked separately"), reference these three files in apply
order under the manifest's scope-tagged patch list.

Cross-references: `marfrit/kernel-agent#12` (the VP9-on-ampere enablement
issue).