Skip to content

kernel: 7.1-rc1 + collabora 12-may + VP9 chewitt stack + AV1 fixes + warn cleanup#6

Closed
dongioia wants to merge 17 commits into
7.1-rc1from
7.1-rc1-may12
Closed

kernel: 7.1-rc1 + collabora 12-may + VP9 chewitt stack + AV1 fixes + warn cleanup#6
dongioia wants to merge 17 commits into
7.1-rc1from
7.1-rc1-may12

Conversation

@dongioia
Copy link
Copy Markdown
Contributor

@dongioia dongioia commented May 12, 2026

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_defconfig che è incluso nel branch.

Costruito col workflow di Bill: rebase su v7.1-rc1, squash-merge di collabora/rockchip-devel in 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)

  1. Squash-merge di collabora/rockchip-devel (2aa600a07eac top, 12 maggio 2026): stack FRL HDMI 2.1 sul bridge dw-hdmi-qp, DTS frl-enable-gpios per i board interessati, audio DP, refactor rkvdec con variant-specific coded fmts, panthor 1.8 firmware-message fixes, DT RK3576.
  2. VP9 HW su VDPU381 e VDPU346 (set dvab-sarma via Chewitt LibreELEC, authorship preservata):
    • FROMLIST(v3) rkvdec: Add support for the VDPU346 variant
    • WIP rkvdec: Add VP9 support for the VDPU381 variant
    • WIP rkvdec: Add VP9 support for the VDPU346 variant
    • WIP 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 alignment
  3. AV1 enablement (Chewitt):
    • FROMLIST(v13) arm64: defconfig: enable Verisilicon IOMMU for Rockchip RK3588
    • LOCAL arm64: dts: rockchip: rk3588: disable nodes that block sync_state()
  4. HDMI audio flood (le tre patch che erano in kernel: 7.1-rc2 + collabora 12-may + VP9 chewitt + AV1 + HDMI flood + VDPU381 PM runtime fix #4):
    • ALSA: pcm_drm_eld: rate-limit ELD parsing errors
    • ASoC: hdmi-codec: bail out silently when sink is disconnected
    • ASoC: soc-utils: do not log -ENOTCONN as ASoC error
  5. Beryllium defconfig:
    • arm64: configs: add beryllium_rk3588_defconfig
    • arm64: configs: beryllium_rk3588_defconfig: bump CMA to 160 MB (più revert additivo drop CONFIG_ROCKCHIP_DW_DP=y per la regressione race-condition di cui sotto)
  6. Pulizia warn dmesg residui:
    • 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 warn Rate 497750000 missing che usciva ogni modeset a 2560x1440 CVT-RB @120 Hz)

Verificato su Rock 5B+ (Beryllium OS)

Test Prima (v7.0.y) Dopo (7.1-rc1-may12)
mpv --hwdec=v4l2request VP9 1080p, 1440p, 4K ok (1440p tested 09/05) ok decode (errors=0 log), 4K render ha ~1-2% drop residuo per sway compositor present-copy
mpv AV1 1080p non tested ok decode (hantro-vpu, errors=0)
Chromium VP9 (V4L2VideoDecoder env opt-OUT LibYUV) 1440p clean via LibYUV CPU bypass decode HW ok, ma artefatti visivi anche a 1080p — workaround LibYUV non più disponibile (pool init fail su panthor 1.8 GBM allocator)
HDMI audio flood, messaggi per boot 152 0
dwhdmi Rate 497750000 missing warn 2 al modeset 0
sync_state pending devices al boot 6 1 (fde50000.dp cosmetic, USB-C DP alt-mode unused)
panthor MCU fatal regression sì su 7.0.0+ overclock no, 1.8.0 stabile

Note sulla regressione DW_DP race-condition: il commit dw_dp: enable DW_DP and bump CMA provava 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 commit drop CONFIG_ROCKCHIP_DW_DP=y per 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-manager nell'initrd e la copia initrd di NM si prende il bus name. Risolto userspace-side con omit_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 su gbm_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

  • Build via Docker arm64 nativo (KCFLAGS già preconfigurate per cortex-a76)
  • Smoke test su Rock 5B+ vero, mira a vedere FRL training su monitor HDMI 2.1, mpv VP9 HW pulito (decode log errors=0) e boot dmesg pulito
  • Regression VP9 1080p su display HDMI 2.0 normale (senza FRL), per essere sicuri che non si rompa il path TMDS
  • AV1 HW via mpv su /dev/video4 (hantro)

Note workflow Bill

  • Branch nuovo 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.
  • Authorship upstream preservata su tutti i cherry-pick (Detlev Casanova, Christian Hewitt, dvab-sarma, Jonas Karlman, Cristian Ciocaltea).
  • Il bump PKGBUILD lato beryllium-org/sbc-pkgbuilds lo apro a parte.

dongioia and others added 16 commits May 12, 2026 12:30
  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>
@dongioia
Copy link
Copy Markdown
Contributor Author

Aggiornamento del 12 maggio sera: ho aggiunto un commit di revert sopra il branch perché abilitare CONFIG_ROCKCHIP_DW_DP=y rompeva il display in alcune sequenze di boot.

Cosa succedeva: con dw_dp builtin il driver tenta dp@fde50000 probe, che innesca un dependency cycle non risolvibile fra vop@fdd90000, dp@fde50000, phy@fed80000 e l'aux_bridge. Il display-subsystem resta in deferred-probe, HDMI non si alza, sway crashava in DRM init e greetd entrava in loop di restart. Su un reboot caldo capitava di vedere ancora il desktop, su altri tutto nero.

Il revert tiene CONFIG_CMA_SIZE_MBYTES=160 ma toglie ROCKCHIP_DW_DP=y. Il warn sync_state() pending due to fde50000.dp torna a comparire, è cosmetico (il device è il DP USB-C alt-mode, che su Rock 5B+ usato come HTPC HDMI non serve). La patch dw_dp: add no-op sync_state callback rimane nel branch, è una no-op finché il driver non viene compilato, quindi non danneggia nulla.

Push diretto sopra il branch esistente (no force-push, è un fast-forward).

@dongioia
Copy link
Copy Markdown
Contributor Author

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

@dongioia dongioia closed this May 18, 2026
dongioia added a commit to dongioia/sbc-pkgbuilds that referenced this pull request May 18, 2026
…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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants