On 31.07.2025 23:06, Maíra Canal wrote:
> Currently, when we prepare or unprepare RPi's clocks, we don't actually
> enable/disable the firmware clock. This means that
> `clk_disable_unprepare()` doesn't actually change the clock state at
> all, nor does it lowers the clock rate.
>
> >From the Mailbox Property Interface documentation [1], we can see that
> we should use `RPI_FIRMWARE_SET_CLOCK_STATE` to set the clock state
> off/on. Therefore, use `RPI_FIRMWARE_SET_CLOCK_STATE` to create a
> prepare and an unprepare hook for RPi's firmware clock.
>
> As now the clocks are actually turned off, some of them are now marked
> CLK_IS_CRITICAL, as those are required to be on during the whole system
> operation.
>
> Link: https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface
> [1]
> Signed-off-by: Maíra Canal <mca...@igalia.com>
>
> ---
>
> About the pixel clock: currently, if we actually disable the pixel
> clock during a hotplug, the system will crash. This happens in the
> RPi 4.
>
> The crash happens after we disabled the CRTC (thus, the pixel clock),
> but before the end of atomic commit tail. As vc4's pixel valve doesn't
> directly hold a reference to its clock – we use the HDMI encoder to
> manage the pixel clock – I believe we might be disabling the clock
> before we should.
>
> After this investigation, I decided to keep things as they current are:
> the pixel clock is never disabled, as fixing it would go out of
> the scope of this series.
> ---
> drivers/clk/bcm/clk-raspberrypi.c | 56
> ++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 55 insertions(+), 1 deletion(-)
This patch landed recently in linux-next as commit 919d6924ae9b ("clk:
bcm: rpi: Turn firmware clock on/off when preparing/unpreparing"). In my
tests I found that it breaks booting of RaspberryPi3B+ board in ARM
32bit mode. Surprisingly the same board in ARM 64bit mode correctly
boots a kernel compiled from the same source. The RPi3B+ board freezes
after loading the DRM modules (kernel compiled from arm/multi_v7_defconfig):
---->8---
[ 7.317423] cfg80211: Loading compiled-in X.509 certificates for
regulatory database
[ 7.379464] Console: switching to colour dummy device 80x30
[ 7.407475] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[ 7.434647] input: vc4-hdmi HDMI Jack as
/devices/platform/soc/3f902000.hdmi/sound/card0/input0
[ 7.448937] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
[ 7.455677] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
[ 7.462371] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4])
[ 7.468962] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops
vc4_crtc_ops [vc4])
[ 7.476424] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops
vc4_crtc_ops [vc4])
[ 7.483831] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops
vc4_crtc_ops [vc4])
(system frozen at this point)
> ...
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
