Regulators in suspend
balajirrao at openmoko.org
Mon Dec 1 16:21:25 CET 2008
On Mon, Dec 01, 2008 at 03:08:10PM +0000, Andy Green wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Somebody in the thread at some point said:
> Hi Mark -
> | This code looks dodgy, by the way - the client really should know if it
> | 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.
> |> However, regulator_is_enabled() is giving a result for the actual state
> |> of the regulator, via a (ops->blah)() thing, but the _enable() and
> |> _disable() guys are looking first at the logical state they hold about
> |> if they enabled or disabled the regulator.
> | 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 guess the answer is to solve them getting out of step, but it's a
> | 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.
> |> funny feature that the regulator struct seems to be opaque for clients
> |> by design (fair enough) and there is no export to find logical state
> |> about their enable either.
> | 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.
And, I don't understand why enabling an already enabled regulator should
result in a warning.. May be I don't know of real life examples where
such a thing would be cause side effects. I was thinking along the lines
of kfree, which doesn't shout if a NULL pointer is passed to it..
More information about the openmoko-kernel