Re: [PATCH v4] clk: expand clk_ignore_unused mechanism to keep only a few clks on

From: Sebastian Reichel
Date: Thu Mar 30 2023 - 11:28:07 EST


Hi,

On Thu, Mar 30, 2023 at 08:06:01AM +0200, Uwe Kleine-König wrote:
> On Wed, Mar 29, 2023 at 02:27:08PM -0700, Stephen Boyd wrote:
> > Quoting Uwe Kleine-König (2023-03-29 13:46:32)
> > > > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > > > > index c3c3f8c07258..356119a7e5fe 100644
> > > > > --- a/drivers/clk/clk.c
> > > > > +++ b/drivers/clk/clk.c
> > > > > [...]
> > > > > @@ -1352,12 +1354,17 @@ static void __init clk_disable_unused_subtree(struct clk_core *core)
> > > > > * back to .disable
> > > > > */
> > > > > if (clk_core_is_enabled(core)) {
> > > > > - trace_clk_disable(core);
> > > > > - if (core->ops->disable_unused)
> > > > > - core->ops->disable_unused(core->hw);
> > > > > - else if (core->ops->disable)
> > > > > - core->ops->disable(core->hw);
> > > > > - trace_clk_disable_complete(core);
> > > > > + if (clk_unused_keep_on) {
> > > > > + pr_warn("Keep unused clk \"%s\" on\n", core->name);
> > > > > + clk_unused_keep_on -= 1;
> > > > > + } else {
> > > > > + trace_clk_disable(core);
> > > >
> > > > We have trace_clk_disable() here. Can you have this tracepoint print to
> > > > the kernel log and watch over serial console? That would be faster than
> > > > bisecting.
> > >
> > > Well no, that doesn't work for all the problems where
> > > clk_ignore_unused=7 could be useful. Consider that e.g. you know that
> > > eth0 is broken, but with clk_ignore_unused is works. So one of the (say)
> > > 25 nominally unused clks are required for eth0. But it's not possible to
> > > test the network after each of the 25 clk_disable()s. Unless I'm missing
> > > something and you can hook a userspace action on a trace line?!
> >
> > In that case it sounds like you want to compile the kernel with the
> > support for enabling clks from debugfs. Can you use that?
>
> In some of the cases that might work. Unless for example the problem
> makes the kernel fail to boot or the device is broken when the clk was
> disabled and reenable doesn't help?!

I recently debugged a similar issue like this:

1. build kernel with CLOCK_ALLOW_WRITE_DEBUGFS
2. boot with clk_ignore_unused, so clocks stay enabled
3. disable clocks via sysfs:
echo 1 > /sys/kernel/debug/clk/${CLK}/clk_prepare_enable
echo 0 > /sys/kernel/debug/clk/${CLK}/clk_prepare_enable
4. check if peripheral is still ok
5. repeat step 3 with the next 'interesting' clock

-- Sebastian

Attachment: signature.asc
Description: PGP signature