Regulators in suspend
andy at openmoko.com
Mon Dec 1 16:57:01 CET 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
|> | 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.
Yes Balaji told about it. But actually I was talking about the case
|> | 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 some more "dodgy" code in probe() for this. Anyway I'll replace
it with the boot_on attribute thing... for bt case it's okay to force it
off and then we at least start on a consistent footing.
-----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