Re: [linux-pm] Power Domain Framework

[Paul Mundt <lethal@linux-sh.org>]

On Wed, May 26, 2010 at 05:07:28PM -0400, Mark Brown wrote:
> On Wed, May 26, 2010 at 10:33:49AM +0200, Sundar R IYER wrote:
> > >needs of the core regulator applications.  As I keep saying I'm just not
> > >seeing much more overlap here with the regulator API than I do with the
> > >clock API: it feels like you've got another use case which needs an API
> > >with a similar structure and the reference counted enable and disable
> > >calls but otherwise very little overlap.
> 
> > As I agreed earlier, its true about requirement. It is also true that the clock API can suffice.
> > But what is essential here is: we are talking about regulators here.
> > Why would we need to model a seemingly similar regulator as a clock?
> 
> You're missing the point here.  I'm not saying use the clock API, I'm
> saying that it feels like you want a parallel API that's aimed at the
> needs of operating points which mirrors the structure of the existing
> clock and regulator APIs.
> 
We did something like this on SH with our hwblk API for dealing with
module power gating, which forms the basis for our runtime PM
implementation. In the SH case we simply have a set of registers that
have on/off control over the bulk of the modules in any given CPU, and we
associate that at the platform device level.

Having said that, building on top of the regulator API for these cases
wouldn't be that much work either, since it largely has all of the
infrastructure in place (ie, the static consumer case).

> It's perfectly sensible for the power domain to be a regulator consumer,
> but having the individual consumer devices be regulator consumers seems
> non-obvious.
> 
The common case on SH is that certain blocks are only available in
certain power domains, while the on/off control remains uniform (albeit
periodically ineffectual) regardless of state. We also don't have any
ability to regulate voltage outside of things like PCMCIA.

On/off control in this context is completely orthoganol from clock
control in that many peripherals without a specific input clock still
implement power gating in the same way as those that do (this is the case
for things like the L2 cache, TLB, breakpoint controller, etc). These are
presently handled through the clock API largely because there was really
no better fit for them at the time.