HVS Core Rate Requirements for KMS

[mripard]

Hi,

It turns out the HVS has a bunch of requirements for the clock rate while it operates depending on both the input and output. Those requirements were completely ignored so far and were ultimately resulting in a vblank timeout.

This implements a proper boost of the core clock based on the planes being used and the pixel valves modes.

[HiassofT]

Thanks, this helped a bit with 4096x2160-30 but the issues are not fully resolved.

Testing on LibreELEC (kernel 5.10.39, May 24 fw) initial boot-up in 4096x2160-30 is fine. But after switching to 1920x1080-60 and then switching to 4096x2160-30 in kodi the screen blanked out after a few seconds (no signal on TV) - and I got flip_done timeout in dmesg.

I could also reproduce that with just modetest (kodi not started at all), simply running modetest -M vc4 -s 32:4096x2160-24 (that shows a picture) and then pressing a key to exit modetest gives no signal, too.

I monitored core freq (with bcmstat), before and during modetest it ran at 277MHz but after exiting modetest it reported 267MHz.

Here's dmesg: http://ix.io/3nX4

[mripard]

I've pushed two fixes that should address the issue you pointed out

[HiassofT]

Thanks, with the updated version 4096x2160-30 is working fine!

When running modetest -M vc4 -s 32:4096x2160-24 core freq now correctly goes down to 267MHz when switching to p24 mode and back to 277MHz when switching back to p30.

Compared to fkms kms doesn't seem to scale core below 267MHz (or 533 with hdmi_enable_4kp60=1) - fkms switches to 220MHz at 640x480-60 but kms runs core at 267 (or 533) MHz.

[mripard]

I had a look and while I don't have 640x480, 720x480 puts the core clock at 200MHz. The firmware reports 200MHz as the minimum clock rate so Linux doesn't try to go below it, but I can't see the 267MHz?

[HiassofT]

I just tested with my 1920x1200 monitor and with that I get 200MHz core clock as well (also on 1920x1200p60 mode). I saw the 267MHz clock when testng with my LG 55C8. Which monitor / edid did you use?

I did another test with my 1920x1200 monitor, using firmware edid override with the LG edid but no kernel / DRM edid override - so FW had the LG edid, configured 3840x2160p30, then linux/DRM read the edid from the monitor and switched to 1920x1200p60 - and that gave 267MHz core clock as well. Quite interestingly clk debug info reported 200MHz min rate. Puzzling.

LibreELEC:~ # vcgencmd measure_clock core
frequency(1)=267231440
LibreELEC:~ # modetest | grep -A 1 ^76
76	224	(0,0)	(1920x1200)
  #0 1920x1200 59.95 1920 1968 2000 2080 1200 1203 1209 1235 154000 flags: phsync, nvsync; type: preferred, driver
LibreELEC:~ # tvservice -s
state 0x120009 [HDMI CEA (95) RGB lim 16:9], 3840x2160 @ 30.00Hz, progressive
LibreELEC:~ # cat /sys/kernel/debug/clk/fw-clk-core/clk_min_rate 
200000000

Here's the config.txt settings I added (I also attached the EDD file):

hdmi_edid_file=1
hdmi_edid_filename=lg-55c8.dat

And these are the KMS config.txt settings we use in LibreELEC:

dtoverlay=vc4-kms-v3d,cma-512
dtoverlay=rpivid-v4l2
disable_overscan=1
disable_fw_kms_setup=1

Anyways, the initial issue of 4096x2160p30 not working is fixed by the PR and this may be a different issue - just wanted to report it.

lg-55c8.zip

[HiassofT]

I did another test: if I force 1920x1080p60 via config.txt, in addition to the fw edid override, I get 200MHz core clock.

LibreELEC:~ # tvservice -s
state 0x120009 [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressive
LibreELEC:~ # vcgencmd measure_clock core
frequency(1)=199995120

config.txt:

hdmi_edid_file=1
hdmi_edid_filename=lg-55c8.dat
hdmi_group=1
hdmi_mode=16

@popcornmix could that be a FW (or fw clock driver) issue, like initial/boot FW core boost not being cleared when kms takes over?

BTW: I also checked with latest FW/kernel, same result (267MHz at 2160p30)

LibreELEC:~ # vcgencmd measure_clock core
frequency(1)=267218256
LibreELEC:~ # tvservice -s
state 0x120009 [HDMI CEA (95) RGB lim 16:9], 3840x2160 @ 30.00Hz, progressive
LibreELEC:~ # vcgencmd version
Jun  8 2021 13:07:19 
Copyright (c) 2012 Broadcom
version 03df0e450c356822f03454c27edea347fd8d211b (clean) (release) (start_x)
LibreELEC:~ # uname -a
Linux LibreELEC 5.10.42 #1 SMP Tue Jun 8 19:10:55 CEST 2021 armv7l GNU/Linux

[popcornmix]

Your guess is likely correct. Initially hdmi mode and framebuffer requires clock boost and are inherited by simple framebuffer in kernel. We don't have a mechanism to know when these are finished with.
We'll have a think about what can be done (may need a new message, so kernel+firmware change).

Forcing a lower pixel clock mode in config.txt is a temporary workaround.

[popcornmix]

I think this is okay to merge. It improves broken 4k output with kms driver.
Getting the correct minimum core frequency needs more work (likely a new kernel->firmware message indicating simple fb is finished with), but is not related to this PR.

[pelwell]

These commits are now in rpi-5.11.y as well, but they'll need patching up for 5.12.

[mripard]

How should we handle this? I guess the easiest would be for me to rebase the branch and send a new PR?

[popcornmix]

@mripard yes, a PR to 5.12 would be welcome.

[6by9]

We appear to have a regression with drm/vc4: Increase the core clock based on HVS load.
See #4401, and reported in passing on dri-devel.
Some flips will blow up tripping the WARN_ON(ctx->contended) in modeset_lock, and then a Unable to handle kernel paging request.

Revert, or wait for a fix?

[popcornmix]

Can you reproduce?

[mripard]

I noticed that some things were off indeed on friday and am working on a fix.

It's taking a bit longer than anticipated, sorry. A revert is fine by me

[6by9]

Can you reproduce?

Yes. Build https://github.com/tomba/kmsxx/ and run utils/kmstest --flip and it'll fall over.
That was with a DSI display attached as well, but I don't think that is a requirement. #4401 is just in X11/Wayland

[popcornmix]

Confirmed - it falls over with hdmi display and utils/kmstest --flip