Files

T

marfrit 9092d9aaaa patches/driver/media: import Sarma's VP9-VDPU381 series (out-of-tree, v8)

Three patches from D.V.A.B. Sarma adding VP9 decode support to the
VDPU381 variant of rkvdec (RK3588 generation). Combined ~1500 LOC,
5 new files in drivers/media/platform/rockchip/rkvdec/.

Provenance: github.com/dvab-sarma/android_kernel_rk_opi branch
add-rkvdec-vdpu381-vp9-v8. Collabora's blog cites the work but it
hasn't reached linux-media patchwork yet (Collabora: "v1 series
needs to be sent for review soon"). Casanova's underlying
VDPU381/VDPU383 H.264+HEVC base IS in mainline 7.0 release.

Tested by author on Orange Pi 5 Pro (RK3588) with AOSP 16 + FFMPEG,
Profile 0 + Profile 2.

Tested in our fleet 2026-05-18: cherry-picks cleanly on top of
ampere-minimal-devices, full kernel build (KERNELRELEASE
7.0.0-rc3-vp9-test+) succeeds clean with GCC 16.1.1. Image + DTB +
modules + initramfs installed under -vp9-test+ suffix on ampere
without touching the running -devices+ kernel; new extlinux label
arch_vp9_test added (default unchanged at arch_devices). End-to-end
VP9 decode verification pending operator reboot into the new label.

Patches NOT yet referenced from fleet/ampere.yaml — that bump is
the operator's call (manifest preamble currently scopes VP9 out per
issue #6). Once verified, ampere.yaml can add these three under the
scope-tagged patch list in apply order 0001→0002→0003.

Cross-reference: marfrit/kernel-agent#12.

2026-05-18 12:56:15 +00:00

3.4 KiB

Raw Permalink Blame History

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).

3.4 KiB Raw Permalink Blame History