Hi, On Fri, Feb 13, 2026 at 03:52:55PM -0300, Maíra Canal wrote: > On some firmware versions, RPI_FIRMWARE_SET_CLOCK_STATE doesn't > actually power off the clock. Document this behavior so that clock > consumers understand they may need to set the rate to minimum before > disabling for meaningful power savings. > > Suggested-by: Stefan Wahren <[email protected]> > Acked-by: Stefan Wahren <[email protected]> > Reviewed-by: Melissa Wen <[email protected]> > Signed-off-by: Maíra Canal <[email protected]> > --- > drivers/clk/bcm/clk-raspberrypi.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/clk/bcm/clk-raspberrypi.c > b/drivers/clk/bcm/clk-raspberrypi.c > index > 9783385d5859836898683209e320fcc928dfdc71..2e63121af0900ac9b4874b666cf6d02baa8be11c > 100644 > --- a/drivers/clk/bcm/clk-raspberrypi.c > +++ b/drivers/clk/bcm/clk-raspberrypi.c > @@ -308,6 +308,12 @@ static void raspberrypi_fw_unprepare(struct clk_hw *hw) > u32 state = 0; > int ret; > > + /* > + * On some firmware versions, RPI_FIRMWARE_SET_CLOCK_STATE doesn't > + * actually power off the clock. To achieve meaningful power consumption > + * reduction, consumers need to set the clock rate to minimum before > + * disabling it. > + */ > ret = raspberrypi_clock_property(rpi->firmware, data, > RPI_FIRMWARE_SET_CLOCK_STATE, &state); > if (ret)
This creates a pretty weird hole in the abstraction layer and clock API. Like, if you set the minimum rate, unprepare the clock, and then put the clock handle, the minimum is not there anymore and you don't have that guarantee anymore. I don't think we ever nailed the semantics of what happens to the clock range once the clock is disabled. And if we do, it's not because a clock consumer disables and clock that it's actually disabled. Couldn't we turn it backward and always set the ideal minimum firmware rate before disabling the clock (possibly by checking the firmware version first) ? Maxime
signature.asc
Description: PGP signature
