Regulators in suspend

[Mark Brown]

On Mon, Dec 01, 2008 at 11:35:53AM +0000, Andy Green wrote:

> We have this kind of construct

> 		if (on) {
> 			if (!regulator_is_enabled(bt_data->regulator))
> 				regulator_enable(bt_data->regulator);
> 		} else {
> 			if (regulator_is_enabled(bt_data->regulator))
> 				regulator_disable(bt_data->regulator);
> 		}

> because the regulator stuff only wants to hear disable on enabled
> regulator and vice versa.

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.

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

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

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