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

[Cristian Ciocaltea <cristian.ciocaltea@collabora.com>]

Hi Thomas,

On 2/14/26 12:00 AM, Thomas Niederprüm wrote:
> Hi Cristian,
> 
> 
> Am Freitag, dem 13.02.2026 um 00:04 +0200 schrieb Cristian Ciocaltea:
>> 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).
> 
> I dumped the kernel messages for a freshly built v6.19 and a linux-next image.
> For each kernel I booted with the suggested debug options and forcing the modes
> 1920x1080@60, 1920x1080@50, 1920x1080@30. The boot logs are attached. For v6.19
> all modes work. Running linux-next, 1920x1080@60 and 1920x1080@50 don't work but
> 1920x1080@30 works.
> 
>> 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.
>>
> 
> As stated above, if I force 1920x1080@30 the screen turns on in linux-next.
> 1920x1080@60 and 1920x1080@50 don't work. This points to something specific to
> the modeline.
> 
> By diff'ing the relevant part of the logs between kernels one can see that in
> the cases where the screen stays black the log lacks the following lines:
> 
>     rockchip-hdptx-phy fed60000.phy: rk_hdptx_ropll_tmds_cmn_config
> rate=185625000 mdiv=155 sdiv=4 sdm_en=1 k_sign=1 k=16 lc=62
>     rockchip-hdptx-phy fed60000.phy: PHY clk ready
> 
> So obviously the PHY clock never gets ready.
> 
> I also attached the diffs I made.

Thanks for checking this out!  The behavior is really unexpected and I'm still
unable to reproduce on my end, i.e. even tested with a Samsung TV, which is
almost as old as yours:

  # Mine
  Vendor & Product Identification:
    Manufacturer: SAM
    Model: 2685
    Serial Number: 1 (0x00000001)
    Made in: week 46 of 2012

  # Yours
  Vendor & Product Identification:
    Manufacturer: SAM
    Model: 1641
    Serial Number: 1 (0x00000001)
    Made in: week 47 of 2009

I added some more debug information, hence could you please apply commit [1] on
your next-20260213 kernel and share the logs after testing again the
1920x1080@50 and 1920x1080@30 modes?

[1] https://gitlab.collabora.com/cristicc/linux-next/-/commit/2ce4b1fb60fc601068abbe9131c05c4f09f1380c

Regards,
Cristian

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy