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

Cristian Ciocaltea cristian.ciocaltea at collabora.com
Thu Feb 12 14:04:29 PST 2026


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 at 60", which should be
anyway the preferred mode (according to the EDID).

Did you try choosing a different one, e.g. 1920x1080 at 50 or 1920x1080 at 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



More information about the Linux-rockchip mailing list