Describe the bug
On a Pi 3 Model B+ running a 6.18 kernel with a KMS/atomic compositor (wlroots/sway), the HDMI output is rejected by the monitor ("Mode Not Supported" on a Samsung S24C650). The EDID is read correctly and 1920x1080@60 (148.5 MHz) is selected as preferred mode, but the pixel PLL never leaves the firmware minimum rate:
# grep -E "pllh_pix|fw-clk-pixel" /sys/kernel/debug/clk/clk_summary
fw-clk-pixel 2 2 0 2400000000 ... 3f902000.hdmi pixel
pllh_pix 0 0 0 86400000 ...
The effective 86.4 MHz pixel clock on 1080p timings yields a ~35 Hz vertical rate, which the monitor rejects. Userspace mode switches (e.g. to 1280x720@60) return success but the clocks never change. No errors in dmesg; the DRM atomic state believes the mode was applied.
Analysis
Commit 0276d66 ("clk: bcm: rpi: Manage clock rate in prepare/unprepare callbacks") sets a firmware clock to its minimum rate on unprepare, and only restores a rate in prepare for clocks flagged maximize (currently v3d). However vc4_hdmi requests the TMDS/pixel rate before enabling the clock (drivers/gpu/drm/vc4/vc4_hdmi.c, vc4_hdmi_encoder_pre_crtc_configure(): clk_set_rate(pixel_clock, ...) followed by clk_prepare_enable(pixel_clock)). After any disable→enable cycle the requested rate is lost and the pixel clock stays at the firmware minimum (86.4 MHz — matching the measurement above).
BCM2711 is unaffected because the HDMI PHY generates TMDS from its internal PLL; BCM2835-37 uses the firmware-managed PLLH path, so all Pi 0-3 on 6.18 with full KMS should be affected. The commit is also present in rpi-6.19.y (350d775).
Workaround (verified)
Reverting 0276d66 on top of 8307cc8 restores correct output — verified on the same hardware/monitor: pllh_pix then locks at 148500000 and the monitor syncs at native 1920x1080@60.
System
- Raspberry Pi 3 Model B+ Rev 1.3
- Kernel: 6.18.39-v8, built from
rpi-6.18.y @ 8307cc8 (vc4 full KMS, dtoverlay=vc4-kms-v3d,cma-256)
- Firmware:
raspberrypi/firmware @ 78e81e2c (24 Jul)
- Compositor: sway 1.11 / wlroots 0.19 (DRM atomic)
- Monitor: Samsung S24C650, EDID preferred DTD 1920x1080@60 (148.500 MHz)
Describe the bug
On a Pi 3 Model B+ running a 6.18 kernel with a KMS/atomic compositor (wlroots/sway), the HDMI output is rejected by the monitor ("Mode Not Supported" on a Samsung S24C650). The EDID is read correctly and 1920x1080@60 (148.5 MHz) is selected as preferred mode, but the pixel PLL never leaves the firmware minimum rate:
The effective 86.4 MHz pixel clock on 1080p timings yields a ~35 Hz vertical rate, which the monitor rejects. Userspace mode switches (e.g. to 1280x720@60) return success but the clocks never change. No errors in dmesg; the DRM atomic state believes the mode was applied.
Analysis
Commit 0276d66 ("clk: bcm: rpi: Manage clock rate in prepare/unprepare callbacks") sets a firmware clock to its minimum rate on unprepare, and only restores a rate in prepare for clocks flagged
maximize(currently v3d). Howevervc4_hdmirequests the TMDS/pixel rate before enabling the clock (drivers/gpu/drm/vc4/vc4_hdmi.c,vc4_hdmi_encoder_pre_crtc_configure():clk_set_rate(pixel_clock, ...)followed byclk_prepare_enable(pixel_clock)). After any disable→enable cycle the requested rate is lost and the pixel clock stays at the firmware minimum (86.4 MHz — matching the measurement above).BCM2711 is unaffected because the HDMI PHY generates TMDS from its internal PLL; BCM2835-37 uses the firmware-managed PLLH path, so all Pi 0-3 on 6.18 with full KMS should be affected. The commit is also present in
rpi-6.19.y(350d775).Workaround (verified)
Reverting 0276d66 on top of 8307cc8 restores correct output — verified on the same hardware/monitor:
pllh_pixthen locks at 148500000 and the monitor syncs at native 1920x1080@60.System
rpi-6.18.y@ 8307cc8 (vc4 full KMS,dtoverlay=vc4-kms-v3d,cma-256)raspberrypi/firmware@ 78e81e2c (24 Jul)