[UPSTREAM - RFC] pm_bt_use_regulator_api.patch

[Mark Brown]

On Wed, Oct 08, 2008 at 10:22:22PM +0530, Balaji Rao wrote:
> Mark Brown <broonie at opensource.wolfsonmicro.com> wrote:

> > > +			if (on) {
> > > +				regulator_set_voltage(regulator,
> > > 3200000, 3200000);

> > I forget from the platform data, is this regulator allowed to vary?
> > If not then just set this in the platform data and let the core do
> > this for you - you only ever set it to one value anyway.

> > regulator_set_voltage() is mostly intended to be used when varying the
> > voltage.

> I didn't get this part. You mean to say that I should set the voltage
> directly and that it should never be required for us to use it
> set_voltage here ?

You should put the constraint in the machine driver with the apply_uV
flag set.  The core will then set the voltage for you.

> > orignal either so no loss there).  The checks for
> > regulator_is_enabled() look a bit odd, though it looks like this is
> > because there's not enough state maintained in the driver to know the
> > state locally.  If the regulator isn't shared it shouldn't make much
> > odds.

> OK. But what if the device is tried to be powered on even when it's
> on ? I found that I get a warning that the regulator is already enabled.

Yes, you will.  The expectation is that the driver will be able to avoid
this by itself - half the issue here is that the regulator API is trying
to point out potential problems in the client code.

The interface you have at the minute is a bit odd in that it looks like
users of this module can just call in and enable or disable the device
at will - if there is more than one user this could mean that the device
will be powered off underneath other users.

> One more thing I wanted to ask is about the suspend/resume handling
> within the regulator API. Is it mainly about saving state before going
> to suspend ? I'm yet to to figure out how to use it.

It's intended for use in configuring the state for the regulators to be
in during suspend.  Many regulator devices have a suspened state of
their own and support separate configuration for use during suspend -
the idea is that you can do things like configure only the supplies you
need for your wakeup sources and preserving memory to be enabled during
suspend.

It's not for saving state during suspend - it's assumed that the
regulator drivers and their clients will deal with that appropriately.