mbox series

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

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

Message

Jonas Karlman June 15, 2024, 5:03 p.m. UTC
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/

Alex Bee (1):
  drm/rockchip: vop: Allow 4096px width scaling

Douglas Anderson (2):
  drm/rockchip: dw_hdmi: Set cur_ctr to 0 always
  drm/rockchip: dw_hdmi: Use auto-generated tables

Jonas Karlman (8):
  arm64: dts: rockchip: Increase VOP clk rate on RK3328
  clk: rockchip: Set parent rate for DCLK_VOP clock on RK3228
  drm/rockchip: dw_hdmi: Fix reading EDID when using a forced mode
  drm/rockchip: dw_hdmi: Allow High TMDS Bit Rates
  drm/rockchip: dw_hdmi: Add max_tmds_clock validation
  drm/rockchip: dw_hdmi: Filter modes based on hdmiphy_clk
  drm/rockchip: dw_hdmi: Enable 4K@60Hz mode on RK3399 and RK356x
  drm/rockchip: Load crtc devices in preferred order

Nickey Yang (1):
  drm/rockchip: dw_hdmi: Add phy_config for 594Mhz pixel clock

Yakir Yang (1):
  drm/rockchip: dw_hdmi: Adjust cklvl & txlvl for RF/EMI

 arch/arm64/boot/dts/rockchip/rk3328.dtsi    |   4 +-
 drivers/clk/rockchip/clk-rk3228.c           |   2 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 173 ++++++++++----------
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |  23 +++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   4 +-
 5 files changed, 116 insertions(+), 90 deletions(-)

Comments

Heiko Stübner June 24, 2024, 4:20 p.m. UTC | #1
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,
Diederik de Haas July 1, 2024, 9:07 a.m. UTC | #2
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
Diederik de Haas July 1, 2024, 9:45 a.m. UTC | #3
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
Christopher Obbard July 4, 2024, 5:10 p.m. UTC | #4
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
Diederik de Haas July 6, 2024, 9:31 a.m. UTC | #5
[Trimmed the list as this is essentially triaging]

On Thursday, 4 July 2024 19:10:36 CEST Christopher Obbard wrote:
> I tested this patch series (together
> with https://patchwork.freedesktop.org/series/134727/) on a Radxa ROCK 4SE

FWIW: That patch set was added to my kernel as well.

> and things appear to work quite well - other than the hotplugging issue
> described below.
> ...
> For the record, with libreelec kernel patches for 4k60 applied to kernel
> 5.something, the above hotplug behaviour does not occur. 

My LE box (Rock64) still needs updating to the 12.x series, but it's running 
LE 11.0.6 with kernel 6.1.74 ...
(FTR: I did my tests with a reasonably bare-bones Debian Trixie system)

> So it must be something introduced in this patch series ?

You're comparing a (likely) heavily patched 5.x kernel to a (mostly vanilla?) 
6.10-rcX based kernel with a potentially completely different kernel config?
If so, I don't think you can draw that conclusion.
But it seems easy to verify by building a kernel with the same 6.10-rcX base, 
but without this patch set applied and do the same tests?

Feel free to contact me privately if you think I could help triaging, but I 
don't think we need to do that on-list.

Cheers,
  Diederik
Heiko Stübner July 29, 2024, 8:21 p.m. UTC | #6
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!

[02/13] clk: rockchip: Set parent rate for DCLK_VOP clock on RK3228
        commit: 1d34b9757523c1ad547bd6d040381f62d74a3189

Best regards,
Heiko Stübner Aug. 15, 2024, 5:31 p.m. UTC | #7
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!

[03/13] drm/rockchip: vop: Allow 4096px width scaling
        commit: 0ef968d91a20b5da581839f093f98f7a03a804f7
[04/13] drm/rockchip: dw_hdmi: Fix reading EDID when using a forced mode
        commit: a5d024541ec466f428e6c514577d511a40779c7b
[05/13] drm/rockchip: dw_hdmi: Allow High TMDS Bit Rates
        commit: 1213b65e436d64611cf74ef8f005b22f6793275f
[06/13] drm/rockchip: dw_hdmi: Add max_tmds_clock validation
        commit: 5f5f657a9c3efe16a2e1455b840c5009f9c75af5
    Fixed the double rk3228 in the commit message.


Best regards,