[PATCH 00/13] rockchip: Enable 4K at 60Hz mode on RK3228, RK3328, RK3399 and RK356x

[Christopher Obbard]

Hi Jonas,

[ + Diederik who has already done some testing ]

On Sat, 2024-06-15 at 17:03 +0000, Jonas Karlman wrote:
> This prepares and enable use of HDMI2.0 modes, e.g. 4K at 60Hz, on RK3228,
> RK3328, RK3399 and RK356x.
> 
> Patch 1-3 fixes some issues to help support use of high-resolution modes.
> 
> Patch 4 fixes reading of EDID on RK3328 when using a forced mode.
> 
> Patch 5-7 adds hdmiphy rate validation in mode_valid so that HDMI2.0
> modes can be enabled on RK3228 and RK3328.
> 
> Patch 8-11 modify phy, current and mpll tables to match what ChromeOS
> and vendor kernel use. These patches originate from old ChromeOS and
> vendor kernels and have successfully been used in LibreELEC distro for
> the past few years.
> 
> Patch 12 enables use of HDMI2.0 modes on RK3399 and RK356x.
> 
> Patch 13 help fix use of console at 4K resolution on RK3399.
> 
> This series may not fully depend on but was only tested together with
> the series "drm: bridge: dw_hdmi: Misc enable/disable, CEC and EDID
> cleanup" at [1].
> 
> I have tested 4K modes on following devices:
> - Asus TinkerBoard (RK3288)
> - Pine64 Rock64 (RK3328)
> - Radxa ROCK Pi 4 (RK3399)
> - Radxa ROCK 3A (RK3568)
> 
> A copy of this series can also be found at [2].
> 
> [1] https://patchwork.freedesktop.org/series/134727/
> [2]
> https://github.com/Kwiboo/linux-rockchip/commits/next-20240531-rk-dw-hdmi-v1/


I tested this patch series (together
with https://patchwork.freedesktop.org/series/134727/) on a Radxa ROCK 4SE and
things appear to work quite well - other than the hotplugging issue described
below.

One problem I did see during testing was in SOME cases, hotplugging a 4k60
monitor didn't seem to show a console or anything on the HDMI output after
replugging (e.g the display shows "no signal"). Sometimes this happened after
the first hotplug, other times it needed a couple of hotplugs to occur. And in
other cases it doesn't happen at all. But once it occurs, there doesn't seem
to be any way to get the device to start transmitting and a reboot (not hard
boot) is needed. It's not clear why it gets into this state.

Another way of getting the device into this state is connecting a 4k60 screen,
then connecting a separate 1080p screen (it's not clear if changing the
resolution from Linux causes the same behaviour), then reconnecting the 4k
screen. In this case, there is no output from the HDMI port. This happens
pretty consistently.

For the record, with libreelec kernel patches for 4k60 applied to kernel
5.something, the above hotplug behaviour does not occur. So it must be
something introduced in this patch series ?


I wonder if you can confirm this bug ?

I will refrain from adding my Tested-by for now.


Thanks

Chris