kernel: 7.1-rc1 + collabora 12-may + VP9 chewitt stack + AV1 fixes + warn cleanup#6
kernel: 7.1-rc1 + collabora 12-may + VP9 chewitt stack + AV1 fixes + warn cleanup#6dongioia wants to merge 17 commits into
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>
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>
|
Aggiornamento del 12 maggio sera: ho aggiunto un commit di revert sopra il branch perché abilitare Cosa succedeva: con Il revert tiene Push diretto sopra il branch esistente (no force-push, è un fast-forward). |
|
Superseded by #4 which consolidates the Frankenstein VP9/AV1/HDMI stack plus the VDPU381 PM runtime teardown fix (LKML v2 submitted at https://lore.kernel.org/all/20260518145414.64514-1-pavone.lawyer@gmail.com/). |
…ime fix Bump pkgrel to 2. Track the rebuilt 7.1-rc2 branch on beryllium-org/linux-beryllium that now consolidates: - Squash-merge of collabora/rockchip-devel as of 2026-05-12 (panthor 1.8, rkvdec HEVC VDPU381/VDPU383, fusb302/tcpm rework, dw-hdmi-qp / samsung-hdptx FRL stack) - VP9 chewitt cherry-picks: VDPU346 + VDPU381 variants, Profile2 support, probs alignment, dvab-sarma fixes - AV1 Verisilicon IOMMU defconfig + sync_state workaround - HDMI flood fix (3 patches) and dw-hdmi-qp N coefficient table for 497.75 MHz pclk - drm/rockchip dw_dp no-op sync_state callback - defconfig CMA 160 MB + DW_DP toggle - VP9 VDPU381 PM runtime teardown fix (Jonas Karlman 2020), sent upstream LKML 2026-05-18: https://lore.kernel.org/all/20260518145414.64514-1-pavone.lawyer@gmail.com/ Validation on Rock 5B+ kernel 7.1.0-rc1+ built from this branch: mpv VP9 1080p+1440p Profile 0 pixel-perfect HW=SW (600/600 random samples, worst delta 0), HEVC+H.264 HW decode no fallback, Chromium V4L2 stateless stable, panthor 1.8 no MCU regression, HDMI audio flood eliminated. Closes beryllium-org/linux-beryllium#6 (superseded by beryllium-org#4).
Summary
Tracking branch per kernel 7.1-rc1 più la testa di Collabora rockchip-devel del 12 maggio, più lo stack VP9 chewitt/dvab-sarma, più i fix AV1, più le tre patch HDMI flood, più la pulizia dei warn DP/HDMI residui. La build usa
beryllium_rk3588_defconfigche è incluso nel branch.Costruito col workflow di Bill: rebase su
v7.1-rc1, squash-merge dicollabora/rockchip-develin un commit unico, cherry-pick dei nostri patch sopra. Supersede #4 (che era su base 7.1-rc2 ed era più magro): qui c'è più collabora, più fix VP9/AV1 e i due fix dmesg che mancavano. Lascio #4 aperto come riferimento, chiudibile a tua discrezione.Branch shape (16 commit oltre v7.1-rc1)
collabora/rockchip-devel(2aa600a07eactop, 12 maggio 2026): stack FRL HDMI 2.1 sul bridgedw-hdmi-qp, DTSfrl-enable-gpiosper i board interessati, audio DP, refactor rkvdec con variant-specific coded fmts, panthor 1.8 firmware-message fixes, DT RK3576.FROMLIST(v3) rkvdec: Add support for the VDPU346 variantWIP rkvdec: Add VP9 support for the VDPU381 variantWIP rkvdec: Add VP9 support for the VDPU346 variantWIP rkvdec: Add VP9 Profile2 support for VDPU346 and VDPU381(10-bit/HDR)WIP rkvdec: Add VP9 fixes from github/dvab-sarma issues(altref vscale + segmap a 524288 per il decode 2K+)FROMLIST(v1) rkvdec: vp9: Fix probs struct alignmentFROMLIST(v13) arm64: defconfig: enable Verisilicon IOMMU for Rockchip RK3588LOCAL arm64: dts: rockchip: rk3588: disable nodes that block sync_state()ALSA: pcm_drm_eld: rate-limit ELD parsing errorsASoC: hdmi-codec: bail out silently when sink is disconnectedASoC: soc-utils: do not log -ENOTCONN as ASoC errorarm64: configs: add beryllium_rk3588_defconfigarm64: configs: beryllium_rk3588_defconfig: bump CMA to 160 MB(più revert additivodrop CONFIG_ROCKCHIP_DW_DP=yper la regressione race-condition di cui sotto)WIP drm/rockchip: dw_dp: add no-op sync_state callback(no-op finché il driver non viene compilato, pronta per riabilitare DW_DP quando upstream sistema il dep cycle)WIP drm/bridge: dw-hdmi-qp: add N coefficients for 497.75 MHz pclk(era il warnRate 497750000 missingche usciva ogni modeset a 2560x1440 CVT-RB @120 Hz)Verificato su Rock 5B+ (Beryllium OS)
--hwdec=v4l2requestVP9 1080p, 1440p, 4KRate 497750000 missingwarnfde50000.dpcosmetic, USB-C DP alt-mode unused)Note sulla regressione DW_DP race-condition: il commit
dw_dp: enable DW_DP and bump CMAprovava ad abilitare il driver dw_dp builtin per silenziare il sync_state. Sul primo boot funzionava, sui successivi (con cmdline cma= diverso) il DT dep cycle vop↔dp↔phy↔aux_bridge non risolveva e display-subsystem restava deferred → display nero e sway crashava. Aggiunto un commitdrop CONFIG_ROCKCHIP_DW_DP=yper tenere solo il bump CMA. Il sync_state warn cosmetico ritorna ma display deterministico. La patch sync_state callback rimane no-op nel branch, pronta per quando upstream rockchip-drm risolverà il cycle.NetworkManager non parte al boot perché dracut include
network-managernell'initrd e la copia initrd di NM si prende il bus name. Risolto userspace-side conomit_dracutmodules+="network-manager …"in/etc/dracut.conf.d/. Non c'entra col kernel quindi non sta in questo branch, ma vale la pena saperlo se qualcuno fa lo stesso build su un'altra installazione.Stato chromium HW acceleration (per onestà)
Su questo kernel il workaround chromium LibYUV CPU bypass (che funzionava a VP9 1440p il 09/05) non è più recuperabile:
image_processor_with_pool.cc::Create()fallisce sugbm_bo_create(AR24, 4K, LINEAR|SCANOUT|TEXTURING)perché il GBM allocator panthor 1.8 rifiuta la combinazione. Mpv funziona HW perché usa libplacebo plane-separate (R8 luma + GR88 chroma) custom shader e non passa per il Skia YUVA combined sampler che ha il bug Mali Valhall. Chromium V4L2VideoDecoder via env opt-OUT LibYUV decode HW ma triggera lo stesso bug Skia → artefatti visivi. Investigazione in corso, non blocca questo PR (kernel-side stack rkvdec/hantro funziona, è chromium che ha problemi suoi).Test plan
/dev/video4(hantro)Note workflow Bill
7.1-rc1-may12, niente force-push (memoria dell'incidente VP9 v8/v9 del 26 aprile). Commit di revert DW_DP=y aggiunto sopra come fast-forward.beryllium-org/sbc-pkgbuildslo apro a parte.