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. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
