> > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/