Re: [patch 2.6.28-rc3] regulator: add REGULATOR_MODE_OFF

[Mark Brown]

On Thu, Jan 15, 2009 at 02:32:30PM -0800, David Brownell wrote:
> On Thursday 15 January 2009, Mark Brown wrote:

> > > That raises an issue:  how can Linux get such regulators to
> > > turn off?  Clock frameworks have the same issue, and they

> > That's something that should be done by constraints - add a new flag
> > that can be set.

> That doesn't make any sense to me, any more than
> adding a per-clock flag would.

Well, the clock API doesn't have the concept of constraints or machine
selectable per-clock options such as those set in constraints - it's the
biggest difference between the two APIs.

> > > I'm thinking it'd be worth having a similar Kconfig option
> > > for regulators too.  It could kick in regulator core code to
> > > call regulator_ops.disable() whenever regulator_dev.use_count
> > > is zero, possibly warning if !regulator_ops.is_disabled().
> > > (Handling constraints.always_on too.)

> > Given the model the API has of not doing anything unless explicitly
> > told to

> ... e.g. by CONFIG_REGULATOR_DISABLE_UNUSED being explicitly
> set, indicating that the regulator support for that platform
> (and its drivers) is complete enough that it can safely paper
> over such early init issues.

Yeah, but user visible things in Kconfig aren't quite the same thing as
having something in the machine definition set it up.  At present
control is very firmly in the hands of the board setup code.

> > I'd not expect to see this as a Kconfig option but rather as 
> > something enabled per regulator or at least per board.

> Why not, though?  That works well with clocks, once the
> drivers are debugged.  Having dozens of fiddly little knobs
> is not an advantage.

There's got to be an explict knob, it's just a question of where it's
exposed.

For machines where it works it's something I'd expect the kernel to just
do without having a Kconfig variable set up.  The machine driver is
already going to have to explictly set up all the regulators that are in
use in the system for this to work so the additional cost of requesting
the feature if it were per-board doesn't feel onerous.  It also means
that people configuring the kernel don't need to worry about how well
the regulators are mapped out, which would be especially useful to
anyone trying to build kernels that run on multiple boards.

> The "boot_on" flag seems redundant with given "always_on"; as
> a rule you can *tell* if the bootloader enabled a supply, so
> the issue is more like whether it should stay on, even when no
> driver wants it on.  Especially considering that bootloaders
> seldom guarantee to enable only a minimal set of supplies.

Yeah, I think that since there's no clean way for clients to disable a
boot_on regulator currently it's only really useful in the very unsual
case where you can't read the regulator state.  If it just enabled the
regulator without incrementing the use count it may possibly useful for
during boot.  I'd need to have a proper think about it to make sure.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/