Re: [RFC PATCH 0/2] Propose critical clocks

From: Marek Vasut
Date: Thu Oct 06 2022 - 07:05:26 EST

On 10/6/22 01:06, Stephen Boyd wrote:
Quoting Marco Felsch (2022-10-05 01:23:48)
Hi Stephen, Michael,

I know it is a busy time right now, but maybe you have a few minutes for
this RFC. I know it is incomplete, but the interessting part is there
and it would fix a real issue we encountered on the imx8mm-evk's.

The i.MX8M hang when using 32kHz supplied by PMIC is solved by modeling the clock in DT correctly, see:

There's another approach by Marek[1]. Can you work together on a
solution? I think we should step away from trying to make the critical
flag work during clk registration, and turn on the clk during provider
registration instead.

So that would work like the qualcomm-specific 'protected-clock' property?

I really want to avoid such clock-driver specific hacks which are poorly or inconsistently supported. This critical-clock should be a generic solution and that should be in clock core.

That hopefully makes it simpler. We can keep the
clk flag of course, so that the clk can't be turned off, but otherwise
we shouldn't need to make registration path check for the property.