Re: [PATCH v7 3/8] cpufreq: kirkwood: Remove use of the clk provider API

[Andrew Lunn]

> > Not quite true. u-boot might of touch the clock. Weird things happen
> > with some kirkwood boards. Some don't have the ability to control
> > there power supplies. So some boards implement "power off" by
> > rebooting, and letting u-boot spin until a button is pressed. I hope
> > such a u-boot powers off as much as possible, and e.g. drops the CPU
> > clock to the lower frequency. One would also hope it puts it back to
> > high speed before calling the kernel.
> 
> I have a doubt about this.
> 
> The powersave clock in drivers/clk/mvebu/kirkwood.c does not set
> CLK_IGNORE_UNUSED, nor do any of the clocks in kirkwood_gating_desc[].
> 
> So regardless of what U-boot does, if no driver has called clk_enable() on
> powersave_clk by late_initcall-time then clk_disable_unused() will
> disable it as a power-saving mechanism.
> 
> So are kirkwood systems that use cpufreq simply getting lucky and not
> hanging?

Hi Mike

Its a good question.

However, the reset value of the clock is off. off means the CPU is
running at its high speed. Turning this clock on, actually reduces the
clock speed! So for 99% of the time, the late_initcall does nothing.

It gets more interesting when uboot, or a previous kernel has turned
the clock on. I admit, i don't expect this to happen very often, but
if it does, and there is no cpufreq driver, interesting things could
happen. The cpufreq driver can only be builtin, not a module. So if it
is available, it should be guaranteed to claim the clock before the
late_initcall could turn it off. And since it reads the hardware
state, it will do the right thing.

       Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/