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

[David Brownell <david-b@pacbell.net>]

On Wednesday 12 November 2008, Liam Girdwood wrote:
> On Wed, 2008-11-12 at 11:25 +0000, Mark Brown wrote:
> > On Mon, Nov 10, 2008 at 08:56:19PM -0800, David Brownell wrote:
>
> > > Less surprising/confusing would be if regulator_{en,dis}able() did
> > > its own refcounting and called down to regulator_dev when changing
> > > a per-client refcount to/from zero.  (Easy patch, for later.)
> > 
> > Yeah, either way is fine for me - don't know if Liam has a strong
> > opinion.  The main benefit of not doing it is that encourages people to
> > avoid consumers sharing the clients which causes problems when clients
> > share the regulator.

Not refcounting enables/disables gets to be a PITA though; that's
why the the IRQ and clock frameworks gave up on the not-counted
versions of their enable/disable calls a long time ago.

The typical problem scenario is that two parts of the same driver
have independent needs to make sure something is enabled.  If it's
not OK to enable() something that's already enabled(), the driver
itself will need to reinvent a refcounting scheme.

That kind of refcount patch would be a net code shrink anyway.  :)


> Fwiw, the main design intention here was to have a 1:1 mapping between a
> consumer device and a struct regulator 

As in, an LCD display and its touchscreen might be in
the same power domain (regulator_dev, internal to the
framework) but would have different regulator structs.

In that case the most likely scenario would be two
drivers needing to enable() so it's not trying to
talk to controllers that are powered off.  Voltage
would normally be fixed.


> so that we could easily store per 
> consumer power data (for mode switching, easier debug, sysfs) and avoid
> any issues between sharing the clients. I'd be happy for this change as
> long as we can keep the per consumer data.

Right, I wasn't talking about changing that model.

- Dave