drm/vc4: Limits fkms to modes <= 85Hz

[alanbork]

Because of commit 883a1a5, the pi4 now ignores configuration set for refresh rates > 85hz. Why is that a good thing? I want to be able to run at 120hz for a hardware project I'm working on. I can patch the code for my own use, but this artificial limit seems wrong-headed, unless there's some issue with the Pi4 hardware that causes errors or other bad behavior > 85hz.

883a1a5

[6by9]

It's things like Kodi where running the display at 1080p100 and 1080p120 are valid if supported by the monitor, but just chew up rendering effort for zero gain.
You could say that Kodi should blacklist the higher refresh rates, but it's easier to do it at the platform level.

If you wanted to submit a PR to move that limit to a module parameter or an optional DT parameter of "raspberrypi,rpi-firmware-kms", then it would be considered.

[alanbork]

That seems like a reasonable compromise, but a little beyond my knowledge of how github works. For my needs I can just patch and recompile locally. But I know I'm not the only one asking for this feature, FYI.

[alanbork]

so this works well (BUT shouldn't the syntax be documented somewhere?) but I'm wondering if there's a related regression when it's not enabled?

I was working with a display that supports 120hz but does not advertise that in the edid (it's a CRT). in order to force the refresh rate I used config.txt to set the hdmi mode to cea 13 (same result holds for dmt 20 and 9), and rebooted. The screen initially came up fine but mid-way though boot it went black and never returned. it turned out I had not figured out the syntax for using this feature and so it wasn't enabled . Once I found the syntax it worked fine and I was able to verify 120hz timing.

BUT: what about when the module parameter wasn't enabled and the screen got turned off mid-boot? that seems like a bad bug indeed given that just keeping the requested mode resulted in a working display. I couldn't determine if it actually tried to set the mode to something else or just disabled video output because it didn't respect my refresh rate request

[6by9]

The max refresh rate has been configurable as a module parameter since July - 8e3b979

The issue of putting an invalid mode on the kernel command line and it resulting in no mode being selected is down to the core DRM code, not the driver. It treats whatever is on the kernel command line as gospel and doesn't fall back to any other mode should the driver reject it. I have had a look at fixing it, but the relevant hooks aren't immediately obvious. I'll ping the contractor who does DRM/KMS stuff for us.

Note you're likely to have issues anyway if you're adding modes not in the EDID. The kernel command line take width, height, refresh rate, and a reduced blanking flag only. It compares w/h/Hz against the EDID advertised modes and selects one of those modes if a match is found, otherwise it uses the CVT algorithm to compute the timings.
CVT generally results in a higher pixel clock from the CEA or DMT modes, and can result in a mode that the monitor can't do.

[alanbork]

good to know about the timings being computed vs standard CEA/DMT. is that an fkms issue or also true on pre-pi4 hardware using the legacy driver?

I suppose there's no hope of having a safe mode boot option ala windows? hold down shift or whatever to selectively apply a subset of the config.txt options marked in [safe]? probably the usb stack's not up early enough to make that work.

instead of a fallback mode perhaps the driver shouldn't reject modes when being initialize for the first time/at boot? then at least you have a hope of working, rather than a guaranteed failure.

[alanbork]

in order to apply this (fkms only) change /boot/cmdline.txt to look something like this:

vc4.fkms_max_refresh_rate=240 console=serial0,115200 console=tty1 root=PARTUUID=d3188030-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait drm/debug=0x14

not needed for kms as far as I can tell.