Regulators in suspend

Andy Green andy at
Mon Dec 1 16:08:10 CET 2008

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.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list