[PATCH v4] GPIO PL061: Adding Clk framework support

Russell King - ARM Linux linux at arm.linux.org.uk
Tue Aug 3 17:23:34 EDT 2010


On Tue, Aug 03, 2010 at 02:40:39AM +0200, Kevin Wells wrote:
> One more item I noted. These changes want to keep the clock enabled
> after the probe - only disabling the clock on amba_remove. Both the
> AMBA peripheral driver (ie, the LCD or MMCI driver) and the amba_remove
> function now disable the clocks.

Absolutely correct.  If we enable the clock for the probe call, and then
disable it afterwards, then what do AMBA bus drivers which have registered
interrupt routines in their probe function do when they receive an
interrupt and want to access their statuc register?

Do we just let them go ahead and fault?  That's just stupid.

No, what we do is create a setup where existing drivers continue to work
without modification - and that means ensuring that the bus clock is
enabled for the duration that the driver is active.

As I've already said, if drivers then want to achieve greater power savings,
they need to use the supplied functions to manage the bus clock - with the
assumption that they will be called with the bus clock already enabled.
If a driver doesn't participate in managing the APB clock, then they don't
need to be modified.

> Wouldn't drivers that use clk_disable in their xxx_suspend functions
> have some problems with this as multiple clk_enables have been called?

Probably, and I left this intentionally open for the time being because
it wasn't clear whether the right action was to disable the bus clock
across a suspend.

However, thinking about it some more, it's probably safe to disable the
bus clock _after_ the driver specific suspend call has successfully
completed, and re-enable it before calling the resume method.  So let's
do this...



More information about the linux-arm-kernel mailing list