Regulators in suspend
broonie at opensource.wolfsonmicro.com
Mon Dec 1 16:37:07 CET 2008
On Mon, Dec 01, 2008 at 03:08:10PM +0000, Andy Green wrote:
> | has enabled the regulator or not and shouldn't be relying on the
> | physical state of the regulator at all if it's not enabled it.
> That breaks down when we inherit dynamic situation from bootloader for
> example. There needs to be a way to adapt to the situation at the
> physical regulator, maybe it should happen by default since there is a
> way to sense it.
Right, that's the main use case I mentioned for the existing
is_enabled() - bootstrapping. The driver can look at the state when
it's starting up and set itself up appropriately. That would include
enabling the regulator if desired.
> | Right, the regulator may be shared, may be forced on by the machine
> | constraints or may be left powered on at startup so the soft and hard
> | states may diverge.
> It seems an API to get an elected consumer to adopt the state of the
> real regulator might not be a bad thing.
I'm not sure what you anticipate this doing? You can force the state of
the regulator at startup via the machine constraints.
> | The real fix is for the driver to know if it wants the regulator to be
> | enabled and track that.
> The situation can be the driver actually wants to adopt inherited
> regulator physical state. The "dodgy" code is trying to do that.
It's never keeping track of the state it wants at all, it's attempting
to force a particular physical state without reference to the logical
state. If it were keeping track of the state it wants it would only do
so at startup.
> | There's not been any demand before, TBH - the main use case for the
> | existing API is bootstrapping.
> It seems funny the "query" and the "set" operations in this API don't
> involve the same state.
Yes, that's true for enabled.
More information about the openmoko-kernel