drm/vc4: Initialization hangs when HDMI display is *not* connected

[kFYatek]

I was working on #4406, and after rebasing the changes onto the current rpi-5.10.y head (e6410af), I found that my Pi3 freezes when trying to initialize the vc4 module. This is not related to my changes, as it happens on e6410af without any changes as well.

After some investigation, I found that everything worked fine after connecting an HDMI display. I was then also able to successfully switch to composite output afterwards through xrandr.

This seems to be somehow related to the 94bc403 commit - the best fix I could find is:

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 5401b6a6f440..768c26b08c15 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -2316,14 +2316,6 @@ static int vc4_hdmi_bind(struct device *dev, struct device *master, void *data)
                        vc4_hdmi->disable_4kp60 = true;
        }
 
-       /*
-        * We need to have the device powered up at this point to call
-        * our reset hook and for the CEC init.
-        */
-       ret = vc4_hdmi_runtime_resume(dev);
-       if (ret)
-               goto err_put_ddc;
-
        pm_runtime_get_noresume(dev);
        pm_runtime_set_active(dev);
        pm_runtime_enable(dev);

although I don't dare proposing that as a permanent fix, because a) it does not seem to make any sense, b) the Pi still freezes after hot-plugging the HDMI display after having booted without one.

Please excuse me for taking the liberty to tag @mripard in advance - you're the author of that commit, maybe you'll make some sense of it.

Please also note that I did not test any of that behavior on Pi4 (yet).

[mripard]

Indeed, @HiassofT reported it on slack earlier this week too, and I'm currently looking into it.

I'm not sure why you're saying that this part doesn't make sense though?

So far I haven't been able to find what's going on exactly, but it seems to be related to the configuration options on the board. The one used by LibreElec are broken just like yours, but mine aren't for the exact same kernel, board and boot method. Could you share yours?

[kFYatek]

I'm not sure why you're saying that this part doesn't make sense though?

Well, there's a reason (clearly stated in the comment) why you added this call that I removed in my quickfix. And while I don't know much about those power management APIs, as far as I understand, that pm_runtime_put_sync() near the end of the function is supposed to indirectly call vc4_hdmi_runtime_suspend() if the port is not used, effectively forming a clk_prepare_enable() ... clk_disable_unprepare() block as it is supposed to be used. By removing the vc4_hdmi_runtime_resume(), it looks that I'm removing the initial clk_prepare_enable().

However, like I said, I don't know much about the kernel's PM API, so I might be missing something or maybe my analysis is completely wrong.

Could you share yours?

I suppose you mean config.txt? Here you go. It's mostly just defaults, taken from a default Raspberry Pi OS installation from around May 2021, just with the Full KMS driver enabled. All the DTB and DTBO files are taken from the freshly compiled kernel.

BTW, I used firmware revision dc6dc9bc6692d808fcce5ace9d6209d33d5afbac from rpi-update, which seems to be the latest there at the moment. The problem also occurred with the original kernel that goes along with that firmware version.

[mripard]

My bad, I thought you were saying the part you removed didn't make any sense, not that removing it didn't :)

I just found out what made it work in my config.txt, it's hdmi_force_hotplug=1, and neither you nor LibreElec are using it, so it seems consistent. Could you try adding it and see if it fixes it on your side too?

[kFYatek]

Well... yes and no. When I enable hdmi_force_hotplug, the board does not freeze and I can SSH to it, but there is absolutely no video on the composite output (neither during the initial firmware phase nor when X is supposed to start - X does not start at all in fact), and not even on HDMI if I hotplug it later.

I looked into dmesg and there are some nasty things there in that scenario.

[mripard]

I've had it occur a couple of times, but it does look like there's some initialisation or resources taken in the firmware that isn't picked up on, and / or leaves the firmware in a weird state.

@popcornmix, @6by9 do you know what could cause this?

[mripard]

I tested whether it would be the video= parameter set by the firmware on the kernel command line that would cause it, but running without hdmi_force_hotplug but with disable_fw_kms_setup doesn't change anything, so it does look like we fail to enable some resource in the kernel and were relying on it to be enabled by the firmware.

[popcornmix]

@mripard can you clarify exactly what isn't working for you?

I was interpreting this thread as some firmware setup of hdmi is required by kms driver which makes booting with hdmi uplugged (so firmware doesn't do it's setup) and then plugging in hdmi (or using something like video=HDMI-A-1:1920x1200M@60e) would fail.

But I'm not seeing that. e.g. with:

disable_fw_kms_setup=1
hdmi_force_hotplug=0

and
video=HDMI-A-1:1920x1200M@60e

and booting with no hdmi connected has no errors in dmesg, and subsequently plugging in hdmi produces expected output.

[HiassofT]

@popcornmix the minimal setup to reproduce the issue here is stock cmdline.txt and config.txt only containing the single line

dtoverlay=vc4-kms-v3d

Booting RPi3B+ with no HDMI connected hangs.

serial console output with current rpi-update kernel/fw: http://ix.io/3tRY

adding disable_fw_kms_setup=1 to config.txt and video=HDMI-A-1:1920x1200M@60eto cmdline.txt doesn't help either http://ix.io/3tS2

Only adding hdmi_force_hotplug=1 lets the RPi3B+ boot without HDMI connected (even with disable_fw_kms_setup=1 and no video= in cmdline.txt).

RPi4 doesn't suffer from that, it boots just fine without any HDMI connected.

[popcornmix]

@mripard I've added some logging and we hang in vc4_hdmi_reset which is where the first writes to any hvs/hdmi
hardware occur. I believe this is because clocks are not running. Most likely this one:

bcm2708: HDMI SM = 0.000 MHz

Note: if we boot without hdmi connected, on a Pi0-3, the firmware will configure VEC (composite) output.
It won't touch the HDMI block. It won't enable clocks needed by it (it will configure the VEC clock to 108MHz).

hdmi_force_hotplug=1 switches this around and VEC won't be configured, but HDMI will be.

Pi4 swaps the default and configures hdmi output unless enable_tvout=1 is set.

So the real issue is kms driver needs to setup whatever clocks are required before accessing registers.
Let me see if enabling HDMI SM clock on firmware is sufficient to get past that point, or if more is needed.

[sans-c]

Not sure if this is helpful or even related but blacklisting the snd module did the job for me as a workaround. For unrelated reasons I was suspecting something sound related after my headless raspberry pi stopped booting after an update and only went through when a monitor was attached.