Regulators in suspend

Andy Green andy at
Mon Dec 1 16:57:01 CET 2008

Hash: SHA1

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
below again.

|> | 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.

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


More information about the openmoko-kernel mailing list