On 4.10.2023 14:52, Bryan O'Donoghue wrote: > On 04/10/2023 13:08, Dmitry Baryshkov wrote: >> On Wed, 4 Oct 2023 at 12:27, Bryan O'Donoghue >> <bryan.odonoghue@xxxxxxxxxx> wrote: >>> >>> On 04/10/2023 01:31, Dmitry Baryshkov wrote: >>>> clk_rcg2_shared_ops implements support for the case of the RCG which >>>> must not be completely turned off. However its design has one major >>>> drawback: it doesn't allow us to properly implement the is_enabled >>>> callback, which causes different kinds of misbehaviour from the CCF. >>>> >>>> Follow the idea behind clk_regmap_phy_mux_ops and implement the new >>>> clk_rcg2_parked_ops. It also targets the clocks which must not be fully >>>> switched off (and shared most of the implementation with >>>> clk_rcg2_shared_ops). The major difference is that it requires that the >>>> parent map doesn't conain the safe (parked) clock source. Instead if the >>>> CFG_REG register points to the safe source, the clock is considered to >>>> be disabled. >>> >>> Why not have a new bit in .flags ? >>> >>> Instead of lying about the clock being off, mark the clock as "parked", >>> or "safe parked" or whatever term we choose for it ? >> >> The main problem with adding flags doesn't fully scale. From the CCF >> perspective, what should be the difference between parked and disabled >> clocks? How should it treat the parked one? > > Exactly the same as a disabled clock, except you get a "parked" instead of a "disabled" when looking up its state and you don't have to The thing is that currently there's only the notion of "enabled" or "not enabled".. Introducing a third state here would be the jump from boolean to quantum logic! I think that abstracting this information away from Linux is not an issue.. These clocks "can't be any more off", or the SoC will explode badly and Linux will be unusable.. Think of it like CPUs with a hypervisor, you shut them down, but the physical number crunchers on the host CPU may not actually get cut off from their power source, but there's no reason for the VM to know that. That's probably what happens on our little virtualized snapdragons anyway.. Konrad
