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

Diederik de Haas
2024-07-01T09:08:06Z

[-- Attachment #1: Type: text/plain, Size: 3124 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]