Regulators in suspend

[Mark Brown]

On Mon, Dec 01, 2008 at 03:08:10PM +0000, Andy Green wrote:

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

Right, that's the main use case I mentioned for the existing
is_enabled() - bootstrapping.  The driver can look at the state when
it's starting up and set itself up appropriately.  That would include
enabling the regulator if desired.

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

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

Yes, that's true for enabled.