| Message ID | 20240615170417.3134517-1-jonas@kwiboo.se (mailing list archive) |
|---|---|
| Headers | show |
| Series | rockchip: Enable 4K@60Hz mode on RK3228, RK3328, RK3399 and RK356x | expand |
On Sat, 15 Jun 2024 17:03:51 +0000, Jonas Karlman wrote: > This prepares and enable use of HDMI2.0 modes, e.g. 4K@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. > > [...] Applied, thanks! [01/13] arm64: dts: rockchip: Increase VOP clk rate on RK3328 commit: 0f2ddb128fa20f8441d903285632f2c69e90fae1 Best regards,
Hi Jonas, On Saturday, 15 June 2024 19:03:51 CEST Jonas Karlman wrote: > This prepares and enable use of HDMI2.0 modes, e.g. 4K@60Hz, on RK3228, > RK3328, RK3399 and RK356x. > ... > 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]. > [1] https://patchwork.freedesktop.org/series/134727/ I only just now realized this part of your message and consequently I had NOT applied the referenced patch set. > I have tested 4K modes on following devices: > - Asus TinkerBoard (RK3288) > - Pine64 Rock64 (RK3328) > - Radxa ROCK Pi 4 (RK3399) > - Radxa ROCK 3A (RK3568) And I can confirm that this patch set enables 4K(@60Hz) resolution when connecting my Rock64 to my 4K TV with my self-build 6.10-rc5 kernel. It selected the 3840x2160@60Hz resolution, but ``swaymsg -t get_outputs`` also reported a range of 4096x2160 resolutions. In contrast, my 6.10-rc2 kernel which is quite similar, except for this patch set, does not mention any 4K resolution at all. So AFAIC you can already include: Tested-by: Diederik de Haas <didi.debian@cknow.org> Next up will be a test with my Quartz64 Model B (RK3566). Not caused by this patch set, but I did encounter several 'interesting' issues while testing it. As most do involve display/hdmi, I'll mention them to have it at least publicly documented. Summary of those: 1) With Debian's 6.8.12-1 kernel I got a stack trace and (initially) no output at all. After some time (due to no signal) my TV turned itself off (standby) and when I turned it on, I did see a console... First line of stack trace: WARNING: CPU: 0 PID: 432 at drivers/media/cec/core/cec-adap.c:1085 cec_received_msg_ts+0x52c/0xbb8 [cec] 2) The 6.9.7 Debian kernel I then installed did not have the stack trace and did show a console, but in 1080p. But I have a 'vague' recollection that the stack trace issue only happens sometimes. 3) All the kernels I tested had the following errors: rockchip-pm-domain ff100000.syscon:power-controller: failed to get ack on domain 'hevc', val=0x88220 gpio-syscon ff100000.syscon:gpio: can't read the data register offset! hdmi-audio-codec hdmi-audio-codec.9.auto: Only one simultaneous stream supported! hdmi-audio-codec hdmi-audio-codec.9.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -22 4) And they also had the following warnings: rockchip-spi ff190000.spi: Runtime PM usage count underflow! dwc2 ff580000.usb: supply vusb_d not found, using dummy regulator dwhdmi-rockchip ff3c0000.hdmi: supply avdd-0v9 not found, using dummy regulator dwhdmi-rockchip ff3c0000.hdmi: supply avdd-1v8 not found, using dummy regulator hdmi-audio-codec hdmi-audio-codec.9.auto: Only one simultaneous stream supported! hdmi-audio-codec hdmi-audio-codec.9.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -22 Those 'dummy regulator' messages got repeated numerous of times, 36 in total. The hdmi-audio-codec only appeared after logging in, so likely 'triggered' by the start of pipewire. Cheers, Diederik PS: and now Q64-B is really up, will report that separately
Hi Jonas, On Monday, 1 July 2024 11:07:50 CEST Diederik de Haas wrote: > On Saturday, 15 June 2024 19:03:51 CEST Jonas Karlman wrote: > > This prepares and enable use of HDMI2.0 modes, e.g. 4K@60Hz, on RK3228, > > RK3328, RK3399 and RK356x. > > ... > > 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]. > > [1] https://patchwork.freedesktop.org/series/134727/ > > I only just now realized this part of your message and consequently > I had NOT applied the referenced patch set. > > > I have tested 4K modes on following devices: > > - Asus TinkerBoard (RK3288) > > - Pine64 Rock64 (RK3328) > > - Radxa ROCK Pi 4 (RK3399) > > - Radxa ROCK 3A (RK3568) > > And I can confirm that this patch set enables 4K(@60Hz) resolution when > connecting my Rock64 to my 4K TV with my self-build 6.10-rc5 kernel. > It selected the 3840x2160@60Hz resolution, but ``swaymsg -t get_outputs`` > also reported a range of 4096x2160 resolutions. > > In contrast, my 6.10-rc2 kernel which is quite similar, except for this > patch set, does not mention any 4K resolution at all. > > So AFAIC you can already include: > Tested-by: Diederik de Haas <didi.debian@cknow.org> > > Next up will be a test with my Quartz64 Model B (RK3566). The Q64-B test results were a bit different from Rock64's, but this patch set enabled the 4K@60Hz resolution as well. 1. The console output was at 1080p, whereas it also switched to 4K on the Rock64. I actually prefer this behavior. 2. After starting sway, it did switch to a 4K resolution, but this time it selected 4096x2160@30Hz on an unpatched kernel (my 6.10-rc2 and Debian 6.9.7). With my 6.10-rc5 kernel *with* this patch, it selected 3840x2160@60Hz 3. None of those 'other' issues I reported with Rock64 showed up on Q64-B :-D IOW: Also for the Pine64 Quartz64 Model B, you can add: Tested-by: Diederik de Haas <didi.debian@cknow.org> Cheers, Diederik
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@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