Power Domain Framework
in [Kernel]
|
Prev: [OOPS] apbuart.c: Two problems related to grlib_apbuart_configure()
Next: Resierfs random corruptions (probably related to cryptsetup or LVM)
From: Sundar R Iyer on 18 May 2010 02:10 Hi, > Yeah, sure - obviously, the generic concept of power domains is > something that does exist within the off-SoC hardware, but on-SoC the > end implementation is a bit different. Exactly. This is what I can see if we can bridge this "a bit different". True, I am dumb to miss out some points, but I think with more inputs, more thinking, we can definitely make it generic! Thinking out loud ( excuse me if this is dumb), At the end of the day, how I see this benefiting a lay driver developer is : use the regulator API for the appropriate power sources - your SoC domain, your external regulator domain..etc..etc and ensure a very efficient (probably) run time PM for your device. All that the Platform guy will do is iterate a list of domains on the platform, provide hookups, ensure constraints etc and the job is done. Even if the same IP is used on a different SoC, you still ensure efficient savings in your driver itself. > As I said in reply to the patch I am concerned that this may be an > oversimplification relative to what general hardware needs. Ohh. for the patch set, as I said, its only a primitive implementation. With your inputs, we can definitely make it more efficient! Regards, Sundar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mark Brown on 23 May 2010 23:40 On Sat, May 22, 2010 at 09:32:10AM +0530, Sundar wrote: > > operating mode for the entire power domain. For example, I can see > > hardware requiring that if more than a given number of blocks are > > enabled at any level a higher operating point is selected. > To me, since such a requirement is a constraint on the regulator, > this can be added as a flag to the regulator details. > This flag can then be used in the set_opp* functions to check the > condition along with the client dependencies! This is just one example of something that might come up and need fitting in to the regulator API which is substantially different to the 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. I don't think the enable and disable calls are enough of an overlap to mean that the regulator use case and the operating point use case are going to overlap well, it feels like it'd cause pain trying to match the concepts between the two APIs. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Sundar R IYER on 26 May 2010 04:40 Hello Mark, >-----Original Message----- >From: Mark Brown [mailto:broonie(a)opensource.wolfsonmicro.com] >This is just one example of something that might come up and need >fitting in to the regulator API which is substantially different to the >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? >I don't think the enable and disable calls are enough of an overlap to >mean that the regulator use case and the operating point use case are >going to overlap well, it feels like it'd cause pain trying to match the >concepts between the two APIs. Again here, more similarities for a power domain with a regulator. 1. Both power domains and a regulator can be enabled/disabled. 2. Both power domains and a regulator can be controlled to a specific voltage. 3. Every peripheral is dependent on both power domains and a regulator to be essentially on. Turning off the clocks will disable the peripheral, but it is not the same as turning off the peripheral. And here is where the biggest difference from the clock API. You can disable the peripheral clock with the clk_disable, but turning it off will be encroachment there. Whilst a regulator_disable is the most logical fit here. 4. Both power domains and a regulator can be enforced upon constraints from their clients. *What* power domains and regulators differ about is: 1.a the nature of constraints is a bit different. On SoC regulators aka power domains have usually a fixed set of clients which don't vary, but off SoC regulators can have varying clients. 2.a On SoC regulators aka power domains allow you controlling operational states like On/Off/Retention/Idle etc, whilst conventional regulators are more happy judging their current loads. However, this still doesn't stop anyone from actually adding operational states to regulators. I agree with your reservations about pains trying to co-relate exactly a power domain and a regulator. If you agree, from the top, reaching out to bottom, there are only subtle differences and these differences (1.a/2.a) can also be incorporated into conventional regulators which can be gradually diminishing, whereas the similarities, (1,2,3,4) can only possible increase! Thanks, Sundar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mark Brown on 26 May 2010 20:40 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. > 1. Both power domains and a regulator can be enabled/disabled. > 2. Both power domains and a regulator can be controlled to a specific voltage. This isn't universal by any stretch of the imagination and manner in which this is done is very different to how a regulator consumer would operate. A regulator consumer knows which voltage it wants to work at directly and is selecting that voltage purely for itself, generally in a way that applies to all implementations of the device. With an operating point a voltage is not set by the individual consumer but rather for the power domain as a whole based on the needs of all the consumers in the power domain. If the same consumer driver is used in multiple SoCs it's likely that the particular voltages needed will vary depending on the implementation on a given device. 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. > 3. Every peripheral is dependent on both power domains and a regulator to be essentially > on. Turning off the clocks will disable the peripheral, but it is not the same as turning off > the peripheral. And here is where the biggest difference from the clock API. You can disable > the peripheral clock with the clk_disable, but turning it off will be encroachment there. Whilst > a regulator_disable is the most logical fit here. This is very much dependant on hardware again, some devices require a clock for even basic functionality such as register access and there are things such as dynamic RAM which won't even provide retention if they are declocked. You also need to remember that a key part of the operating point configuration of some devices is the clock rate - normally the voltage required by the block will be driven by the clock rates in operation in the block. The clock rates required may be a function of the operation of the individual blocks but are often also driven by things like the overall bandwidth needed on the various buses in the system. As I keep saying the operating point selection in general hardware is often a function of both the clocking and voltage selection, and often chosen in a different way. > 4. Both power domains and a regulator can be enforced upon constraints from their clients. A different set of constraints, though - there's not much overlap here. > *What* power domains and regulators differ about is: > 1.a the nature of constraints is a bit different. On SoC regulators aka power domains have usually > a fixed set of clients which don't vary, but off SoC regulators can have varying clients. As I keep saying the interaction between the consumer and the supplier is also rather different between the two use cases. > 2.a On SoC regulators aka power domains allow you controlling operational states like > On/Off/Retention/Idle etc, whilst conventional regulators are more happy judging their current loads. > However, this still doesn't stop anyone from actually adding operational states to regulators. Can you identify how operating points might be added to regulators? The physical connection between the regulators and the devices they are supplying is very clear and does not leave much (if any) room for flexibility here, and as I discussed in a prior message the trend in hardware implementation is towards reducing the control which systems use rather than increasing it. > I agree with your reservations about pains trying to co-relate exactly a power domain and a regulator. > If you agree, from the top, reaching out to bottom, there are only subtle differences and these > differences (1.a/2.a) can also be incorporated into conventional regulators which can be gradually > diminishing, whereas the similarities, (1,2,3,4) can only possible increase! I'm still not seeing any meaningful overlap between the two things - it seems unlikely that a substantial proportion of the drivers that need to interact with operating points will also wish to explicitly use anything other than enable and disable that the regulator API offers so even if the two ended up being implemented in the same API you'd still have two disjoint blocks of code implementing different things. There are many interfaces in the kernel which work together to provide power efficiency and to me it seems like you have identified a need for a new one. I'd also repeat my previous suggestion to look in more detail at the operating point implementations that already exist in the kernel and the needs of the hardware out there. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Paul Mundt on 26 May 2010 23:10
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |