Re: [RFC PATCH 2/3] clk: bd718x7: Enable the possibility to mark the clock as critical

[Matti Vaittinen]

On 8/14/24 19:00, Michael Nazzareno Trimarchi wrote:
> Hi Stephen
>
> On Mon, Jun 6, 2022 at 7:26 AM Matti Vaittinen <mazziesaccount@xxxxxxxxx> wrote:
> > Hi Michael,
> >
> > On 6/5/22 19:57, Michael Trimarchi wrote:
> > > If the clock is used to generate the osc_32k, we need to mark
> > > as critical. clock-critical has no binding description at the moment
> > > but it's defined in linux kernel
> > >
> > > bd71847: pmic@4b {
> > > ...
> > >        rohm,reset-snvs-powered;
> > >
> > >        #clock-cells = <0>;
> > >        clock-critical = <1>;
> > >        clocks = <&osc_32k 0>;
> > >        clock-output-names = "clk-32k-out";
> > > ...
> > > }
> > >
> > > Signed-off-by: Michael Trimarchi <michael@xxxxxxxxxxxxxxxxxxxx>
> > > ---
> > >    drivers/clk/clk-bd718x7.c | 4 ++++
> >
> > //snip
> >
> > > @@ -100,6 +101,9 @@ static int bd71837_clk_probe(struct platform_device *pdev)
> > >
> > >        parent_clk = of_clk_get_parent_name(parent->of_node, 0);
> > >
> > > +     of_clk_detect_critical(dev->of_node, 0, &flags);
> >
> > Purely judging the kerneldoc for of_clk_detect_critical - you may have
> > hard time getting this accepted.
> >
> > I think you're working on a very valid problem though. Maybe you could
> > see if you could align your effort with Marek?
> >
> > https://lore.kernel.org/all/20220517235919.200375-1-marex@xxxxxxx/T/#m52d6d0831bf43d5f293e35cb27f3021f278d0564
>
> Old thread but same problem. Is there any way to make this acceptable?
> any suggestion?

Hi Michael. I'm not sure what is the correct way but I think there are a 
few tricks people have used to fix (or paper over) the problem. One was 
suggested by Sebastian:

https://lore.kernel.org/all/20220913152140.iikckob5h3ecagfi@xxxxxxxxxxxxxxxxxxxxxx/

No one shouted for implementing this fix though.

It also seems to me that there is a way to 'make things work' by 
modelling the clock dependencies in the DT in certain way, AND having 
correct drivers enabled. This understanding came just by reading mails 
Marek sent in this discussion:

https://lore.kernel.org/all/20220924174603.458956-1-marex@xxxxxxx/

I've not tested any of this myself - but I hope you can use these as 
pointers to a solution that works for you...

Yours,
	-- Matti

--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~