On Mon, Feb 16, 2026 at 09:18:31AM -0300, Maíra Canal wrote:
> On 16/02/26 07:53, Maxime Ripard wrote:
> > On Fri, Feb 13, 2026 at 03:52:56PM -0300, Maíra Canal wrote:
> > > If PIXEL_CLK or HEVC_CLK is disabled during boot, the firmware will skip
> > > HSM initialization, which would result in a bus lockup. However, those
> > > clocks are consumed by drivers (vc4 and HEVC decoder drivers,
> > > respectively), which means that they can be enabled/disabled by the
> > > drivers.
> > > 
> > > Mark those clocks as CLK_IGNORE_UNUSED to allow them to be disabled by
> > > drivers when appropriate.
> > > 
> > > Acked-by: Melissa Wen <[email protected]>
> > > Signed-off-by: Maíra Canal <[email protected]>
> > 
> > It looks like sync_state would be a better candidate to handle this?
> 
> I have the impression that CLK_IGNORE_UNUSED is still a better fit here.
> 
> First, the clock framework has no sync_state integration. The only use
> of sync_state in clock drivers is done by Qualcomm's clock controllers,
> which uses icc_sync_state for the interconnect framework.

It's done at the device level, so you don't really need any kind of
integration, you could roll your own implementation.

> From my understanding, CLK_IGNORE_UNUSED is the idiomatic mechanism
> for "don't disable this clock during clk_disable_unused() and allow
> drivers to manage it", which is exactly what we are looking for.

Ish. CLK_IGNORE_UNUSED is kind of a hack that only does the first part
of what you stated. After clk_disable_unused(), all bets are off and for
all you know, all the unused clocks could still be disabled. You can
trigger such a condition if a driver gets and enables the clock, fails
to probe and disables it.

It's been mostly used for clocks that should never be disabled on the
system (and has been superseded by CLK_IS_CRITICAL for this use-case),
or to ignore clk_disable_unused, where sync_state() is the superior
solution.

> Apart from that, if we decide to use sync_state, I'm not sure we could
> handle granularity. sync_state is a per-device mechanism, not per-clock,
> and clk-raspberrypi provides multiple clocks (consumed by different
> drivers). With CLK_IGNORE_UNUSED, the protection is per-clock: once a
> driver calls clk_prepare_enable/unprepare() it manages that clock,
> regardless of what other consumers of other clocks are doing.

sync_state would replace clk_ignore_unused, so would run on the
controller device and disable all active clocks with no users.

But yeah, maybe CLK_IGNORE_UNUSED is good enough still.

Maxime

Attachment: signature.asc
Description: PGP signature

Reply via email to