Regulators in suspend
andy at openmoko.com
Mon Dec 1 16:08:10 CET 2008
-----BEGIN PGP SIGNED MESSAGE-----
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel