Thread (1 message) 1 message, 1 author, 2026-02-12

Re: [REGRESSION] HDMI monitor not working on Radxa Rock 5B after phy rockchip samsung hdptx HDMI 2.1 FRL patchset

From: Cristian Ciocaltea <hidden>
Date: 2026-02-12 22:04:32
Also in: linux-phy, linux-rockchip, lkml, regressions

Hi Thomas,

On 2/11/26 11:20 PM, Thomas Niederprüm wrote:
Hi,

I'm running a Radxa Rock 5B (rk3588) on a 10+ year old Samsung TV screen
connected via HDMI. This worked flawlessly in 6.18.7 but does not work on linux-
next. I bisected the problem and identified commit 3481fc04 to be the first bad
commit. This points to the phy PLL clock rate calculation to be the problem in
connection with my monitor. As it seems relevant, I attached the EDID of my
monitor.

I'm booting the kernel out of EDK2 after which efifb is correctly taking over
the initialized display and I can see the initial kernel boot messages on the
HDMI output. After the drm/kms in the kernel takes over the screen shortly turns
black, changes resolution, and then correctly displays on 6.18.7. However, in
linux-next the screen remains black after kms took over. I cannot see any
obvious differences in the boot logs but I attached two boot logs, one for the
working 6.18.7 kernel and one for the non-working linux-next kernel.

When reverting 3481fc04..de5dba83 (i.e. the faulty commit and the ones that
followed in the HDMI 2.1 FRL series) I can build a working kernel from linux-
next.

I don't know where to dig from here but I'm happy to run any test necessary to
track down the problem.
It'd be helpful if you could resend the logs after booting both kernels with the
following params (requires CONFIG_DYNAMIC_DEBUG=y):

  rockchipdrm.dyndbg=+p dw_hdmi_qp.dyndbg=+p phy_rockchip_samsung_hdptx.dyndbg=+p

As well as running the command below before connecting your display/TV:

  $ echo 0x4 > /sys/module/drm/parameters/debug

I've noticed you're forcing "video=HDMI-A-1:1920x1080M@60", which should be
anyway the preferred mode (according to the EDID).

Did you try choosing a different one, e.g. 1920x1080@50 or 1920x1080@30 (they
are supported according to the listing in CTA-861 Extension Block). That's more
a test to confirm the issue affects a particular modeline, or is more general.

FWIW I've tested over 40 modes with different displays/TVs and didn't notice any
regression, hence I'm probably missing something here.

Thanks for the report!

Cristian
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help