kernel: 7.1-rc2 + collabora 12-may + VP9 chewitt + AV1 + HDMI flood + VDPU381 PM runtime fix#4
Conversation
Top commit: 2aa600a07eac arm64: dts: rockchip: Drop unnecessary
#{address,size}-cells from rk3588-jaguar
Date: 2026-04-30 23:26:29 +0200
Highlights vs v7.1-rc1 mainline:
- HDMI 2.1 FRL stack (drm/bridge dw-hdmi-qp + scdc-helper +
samsung-hdptx phy + vop2 ACLK scaling, 13 commits)
- DTS frl-enable-gpios per Rock 5B/5B+/5T + Rock 5 ITX + jaguar,
rk3588-rock-5b-5bp-5t.dtsi, ecc.
- rkvdec refactor: variant-specific coded_fmts + capability filtering
- drm/bridge-connector: detect_ctx hook + cached connector status
- DP audio support (synopsys dw-dp + RK3576/RK3588 DT)
- fusb302/tcpm typec rework
- rk3588-jaguar DT cleanups
- panthor v1.8 firmware messaging fixes
- rkvdec stack-usage reductions
- Various rkcif/rkisp1 fixes
Source: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux
Branch: rockchip-devel
VDPU346 is similar to VDPU381 but with a single core and limited to 4K60 media. It is also limited to H264 L5.1 and omits AV1 and AVS2 capabilities. VDPU346 is used with RK3566 and RK3568. Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Tested-by: Dang Huynh <dang.huynh@mainlining.org> # Pinetab2
Add a driver and registers to support the VP9 decoder for VDPU381 used with RK3588. NOTE: This is still in development. The driver currently supports VP9 media up to 4K30 (Profile 0). Signed-off-by: Venkata Atchuta Bheemeswara Sarma Darbha <vdarbha0473@gmail.com>
Add VP9 support to VDPU346, limited to 4K modes and Level 5.1. Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
This is experimental and probably incomplete (esp. on VDPU346). Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
See dvab-sarma/android_kernel_rk_opi#3 Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
When building for arm 32 bits, the struct alignment changes and the compiler adds 3 padding bits to the anonymous mv struct in rkvdec_vp9_inter_frame_probs. Therefore, the BUILD_BUG_ON used to check that the struct size is aligned to 128 bits (hardware requirement) fails. As that mv struct is at the end of the global rkvdec_vp9_probs struct and is followed by 11 padding bits, the 3 padding bits can be explicitely set in the mv struct and removed from the 11 following it. This makes sure that the mv struct is 32 bits aligned. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512110229.R6YCf1Le-lkp@intel.com/ Fixes: d968e50 ("media: rkvdec: Unstage the driver") Suggested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
…p RK3588 Enable Verisilicon IOMMU used by Rockchip RK3588 AV1 hardware codec. This hardware block could be found in Radxa Rock 5B board. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
…ate() Disable secondary multi-core video codec nodes (vepu121_1/2/3 and vdec1) that the hantro-vpu and rkvdec drivers explicitly reject with "missing multi-core support, ignoring this instance". These nodes match a driver but probe returns -ENODEV, leaving fw_devlink consumer links unsatisfied and permanently blocking the power domain controller's sync_state(). Also remove the hdmi_receiver status="okay" override from the Rock 5B board DTS since CONFIG_VIDEO_SYNOPSYS_HDMIRX is not enabled, so the node will never probe and similarly blocks sync_state(). With CONFIG_FW_DEVLINK_SYNC_STATE_TIMEOUT unset (strict mode), these unprobed consumers prevent sync_state() from ever completing, keeping unused power domains energised indefinitely. NB: This is a hack and will be dropped in the future once multicore support has been enabled in the kernel. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Mirror of Mark Brown's ASoC: hdac_hdmi rate-limit patch (commit
[lkml.kernel.org/lkml/2025/6/13/1380]) for the generic snd_parse_eld()
helper used by ASoC hdmi-codec.
When a HDMI sink is disconnected (e.g. a board with two HDMI outputs and
only one cable), userspace audio servers like PipeWire keep probing the
disconnected card and trigger:
HDMI: Unknown ELD version 0
at every probe — easily 30+ messages per burst on rk3588. The same
applies to malformed ELD (MNL out of range). Both conditions are
expected when no sink is attached; rate-limit the dev_info() so the
kernel ring buffer does not fill up.
Signed-off-by: Sav <62543096+dongioia@users.noreply.github.com>
When userspace opens the PCM of an HDMI codec whose sink is not connected, get_eld() returns an empty buffer (version field == 0). snd_parse_eld() then logs 'HDMI: Unknown ELD version 0' and the constraint helper ultimately returns -EINVAL, causing the ASoC core to wrap the failure as 'ASoC error (-19): at snd_soc_dai_prepare()'. PipeWire/PulseAudio retry the open at high rate, flooding dmesg even after the rate-limit added in pcm_drm_eld is in place. Detect the empty ELD (version field of byte 0 is zero) up front, return -ENOTCONN, and skip the parse + constraint dance entirely. The ASoC core already silences -ENOTCONN once snd_soc_ret() is taught about it, leaving the ring buffer clean. Signed-off-by: Sav <62543096+dongioia@users.noreply.github.com>
-ENOTCONN is the natural return value for a codec that has no sink attached (HDMI/DisplayPort with no monitor, etc.). It is an expected state, not an error worth printing every time userspace probes the PCM. Treat it the same way as -EPROBE_DEFER and -EOPNOTSUPP: callers still get the negative value back, but the kernel ring buffer is not polluted. Signed-off-by: Sav <62543096+dongioia@users.noreply.github.com>
Optimized config for RK3588 boards based on benchmarked testing: - schedutil governor default (+18.8% SHA256 MT vs performance) - THP madvise mode (reduced TLB pressure) - ZRAM built-in with LZ4 (~30% faster than lzo-rle on ARM64) - ZSWAP available but not default-on - sched-ext (BPF schedulers) with BTF enabled - ARM64 errata reduced to A55/A76/Rockchip only (31 -> 9) - BPF_JIT_ALWAYS_ON, debug overhead removed Tested on Rock 5B+ (RS129-D24E0, 24GB LPDDR5). KCFLAGS: -march=armv8.2-a+crypto+fp16+dotprod -mtune=cortex-a76
Fixes dmesg warn: rockchip-pm-domain ...: sync_state() pending due to fde50000.dp The DP controller probe completes but lacks a sync_state callback to signal consumer-side init done, leaving fw_devlink dependencies in "pending" state. Add a no-op callback that just marks runtime PM busy. Signed-off-by: Sav <62543096+dongioia@users.noreply.github.com>
Adds N-coefficient table entry for pixel clock 497750000 Hz (2560x1440 CVT-RB @120 Hz), fixing dmesg warning: dwhdmiqp-rockchip fde80000.hdmi: Rate 497750000 missing; compute N dynamically Values picked so CTS = pixel_clk * N / (128 * fs) is integer for the audio sample rates standard derives (32k/44.1k/48k and 2x/4x multiples the driver computes from these): - 32 kHz : N = 4096 (CTS = 497750) - 44.1 kHz: N = 14112 (CTS integer; 88.2k -> 28224, 176.4k -> 56448) - 48 kHz : N = 6144 (CTS = 497750; 96k -> 12288, 192k -> 24576) Reference: HDMI 1.4b spec Table 7-1 ratios. Signed-off-by: Sav <62543096+dongioia@users.noreply.github.com>
… to 160 MB CONFIG_ROCKCHIP_DW_DP=y enables the DisplayPort controller driver bound to the fde50000.dp device on Rock 5B+ (USB-C alt-mode). Without it fw_devlink leaves the device unprobed and rockchip-pm-domain logs "sync_state() pending due to fde50000.dp" every boot. Pairs with the no-op sync_state callback added earlier on the dw_dp driver to silence the warning when the device is enabled but unused. The symbol is bool, so =y rather than =m. CONFIG_CMA_SIZE_MBYTES=160 raises the contiguous memory area from the arm64 generic default (64 MB) to give the V4L2 stateless decoders room to allocate buffer pools for VP9 4K (peak ~190 MB with 16 pool slots). Avoids relying on a cma=160M cmdline workaround in GRUB. Signed-off-by: Sav <62543096+dongioia@users.noreply.github.com>
4 tasks
Contributor
Author
|
Aggiornamento del 12 maggio: ho riaperto la cosa su un branch nuovo seguendo il workflow squash-collabora più push come branch nuovo (senza force-push). Lo trovi qua: #6 Rispetto a questo PR, quello nuovo ha:
Lascio aperto questo PR per riferimento, chiudilo pure quando hai dato un'occhiata a #6. |
4 tasks
Enabling the dw_dp driver as builtin reintroduces a DT dependency cycle between vop@fdd90000, dp@fde50000, phy@fed80000 and the aux_bridge that the kernel cannot resolve on cold boot in some configurations. The display-subsystem stays in deferred-probe and the HDMI chain never comes up, so the screen stays blank and greetd loops on sway crashing during DRM init. Keep CONFIG_CMA_SIZE_MBYTES=160 (the other half of the previous patch), revert only the DW_DP enable. The sync_state warn about fde50000.dp returns (cosmetic, the device is the USB-C DP alt-mode and unused on the typical Rock 5B+ HDMI setup). Signed-off-by: Sav <62543096+dongioia@users.noreply.github.com>
The current remove() path calls rkvdec_v4l2_cleanup() and pm_runtime_disable() before pm_runtime_dont_use_autosuspend(), and frees the empty IOMMU domain after that. With autosuspend still armed when the domain goes away, the VDPU381 can be left in a dirty state across module reload and suspend/resume cycles. On RK3588 this surfaces as a VP9 inter-prediction bug: from the second ALTREF frame onward, motion blocks decode with U=V=0 (BT.709 green), while intra and static blocks stay correct. Reordering the teardown to dont_use_autosuspend() -> iommu_domain_free() -> pm_runtime_disable() -> v4l2_cleanup() makes the symptom go away. Tested on a Radxa Rock 5B+ (RK3588, 8 GB LPDDR5) with both the libva-v4l2-request mpv pipeline and Chromium's V4L2 stateless decoder. With the fix, 300 random pixel samples on VP9 Profile 0 clips at 1080p and 1440p match a libvpx software reference exactly (worst delta 0). Without it, the same 1080p sample at frame 4, pixel (960, 270) reads HW=(0,112,0) vs SW=(204,147,116). HEVC and H.264 stateless decoding via mpv keep running on hardware with no fallback. Fixes: ff8c562 ("media: rkvdec: Restore iommu addresses on errors") Link: https://lore.kernel.org/all/20260518145414.64514-1-pavone.lawyer@gmail.com/ Cc: <stable@vger.kernel.org> Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Tested-by: Francesco Saverio Pavone <pavone.lawyer@gmail.com> Signed-off-by: Francesco Saverio Pavone <pavone.lawyer@gmail.com>
dongioia
changed the title
dongioia
added a commit
to dongioia/rock5bplus-rkvdec2
that referenced
this pull request
May 20, 2026
Status updates - Kernel: Linux 7.0 final -> Linux 7.1-rc2 (linux-beryllium-rockchip 7.1.0rc2-2). New active-patches table reflects the Collabora rockchip-devel squash plus the chewitt VP9 / AV1 / HDMI patchset and the `media: rkvdec: fix PM runtime teardown ordering in remove` cleanup accepted to stable on 2026-05-18. - BredOS -> Beryllium OS rename: contributions table now distinguishes pre-transition (BredOS/sbc-pkgbuilds) from post-transition (beryllium-org/sbc-pkgbuilds, beryllium-org/linux-beryllium). - Chromium release reference moves from -2 to -3 (latest published tag). The 16/05 internal AR24 picker + skip-GL-rk3588 patches are documented as an unreleased build on top of -3. Invalidated hypotheses - The VP9 Mali Valhall artifact was previously documented as resolution-gated (>= 1440p). It is not: the Skia / ANGLE shader miscompile fires on every VP9 plane layout. Below 1080p YouTube serves AV1 and the path is simply not exercised. The Chromium section now states this explicitly. - mpv `--hwdec=v4l2request` zero-copy silently falls back to software on Mesa panthor. The recommended hwdec value is now `v4l2request-copy`, both in the mpv.conf snippet and in the bookmarklet handler. New content - libva-v4l2-request fork section (dongioia/libva-v4l2-request, rk3588-vp9): VP9 Profile 0 1080p pixel-perfect via `vaapi-copy`; zero-copy and VLC paths blocked by the Mesa panthor EGL dmabuf import behaviour documented as PHASE 2j-D. - Browser article (docs/bredos-wiki-browser-article.md) gains a section 0 kernel premise, an updated section 5 with the `ffmpeg-v4l2-requests` PKGBUILD requirement, and a section 5.4 userscript that auto-redirects YouTube to mpv at 1080p+. - Changelog entries for 2026-05-11 (-3 release), 2026-05-16 (ImageProcessor AR24 patches), 2026-05-18 (PM runtime fix accepted), 2026-05-19 (libva-v4l2-request pixel-perfect), 2026-05-20 (PHASE 2j-D Mali EGL diagnosis). URLs verified 2026-05-20 (HTTP 200): beryllium-org/linux-beryllium#4, beryllium-org/sbc-pkgbuilds#3, dongioia/libva-v4l2-request, beryllium-org/sbc-pkgbuilds/tree/main/{linux-beryllium-rockchip,ffmpeg-v4l2-requests}, dongioia/rock5bplus-rkvdec2/releases/tag/v147.0.7727.116-3.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Consolidated kernel work targeting 7.1-rc2 with full RK3588 stack for Beryllium daily-driver use on Rock 5B+.
Base
collabora/rockchip-develhead as of 12/May/2026 (panthor 1.8, rkvdec HEVC VDPU381/VDPU383, fusb302/tcpm rework, dw-hdmi-qp / samsung-hdptx FRL stack, drm/bridge detect_ctx, etc.)On-top patches
Validation (Rock 5B+ kernel 7.1.0-rc1+ build of this branch)
Closes
Supersedes #6 (7.1-rc1-may12 Frankenstein), consolidates all VP9/AV1/HDMI work into one PR.