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 17 May 2010 13:50 Hello, > This implementation is assuming that the implementation in hardware only > has two levels, and that the decision to go to the higher level is done > by a simple or of requests for the full level from the consumers. I'm > not convinced that this will be true in general, or that it's always > going to be true that the different power domains are all isolated from > each other. There doesn't seem to be any immediate reason why hardware > won't ever implement more than two modes, and I'm not convinced that the > straight or of requests will always be sufficient to determine the Yes. Two modes is not the only level that hardware can support. An ideal case is Full OPP/Half OPP (which is the normal operating point)/Retention(which is the least so that the device is on). > 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. Hmm...very much possible. Need to think on this further. > Are you sure that this interface is sufficiently general to work with > all hardware, not just your own? How does this map on to the OMAP or SH > hardware, for example? AFAIK and with my experience (and my current memory) with TI Davinci arch, most of the power domains are simpler ones with on/off and possibly some retention too. And the latest TI code also exposes domains with on/off/retention states. So, I think if we make this sturdy, I dont see any reason why we cannot map any generic architecture. CCing Kevin for his inputs. This is one of the most important aspect for such a change in the regulator framework: bringing in the domain aspect can encourage all newer (possibly older) architectures to come under a generic umbrella. Anyways, let me have a bit more on the "number of blocks" thing! 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: Linus WALLEIJ on 17 May 2010 16:40 [Sundar] > This is one of the most important aspect for such a change in the > regulator framework: bringing in the domain aspect can encourage all > newer (possibly older) architectures to come under a generic umbrella. I have the same view, and I've been enouraging Sundar to bring this discussion with the community in order to avoid code duplication. Of course we can start inventing our own power-domain machine like everyone else, but before we do that, let's atleast try to do something generic, so bear with us... Yours, Linus Walleij -- 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 17 May 2010 17:20 On Mon, 2010-05-17 at 22:38 +0200, Linus WALLEIJ wrote: > [Sundar] > > This is one of the most important aspect for such a change in the > > regulator framework: bringing in the domain aspect can encourage all > > newer (possibly older) architectures to come under a generic umbrella. > I have the same view, and I've been enouraging Sundar to bring this > discussion with the community in order to avoid code duplication. > Of course we can start inventing our own power-domain machine > like everyone else, but before we do that, let's atleast try to > do something generic, so bear with us... So, there's two separate issues here: one is if it makes sense to do a generic power domain framework and/or, and the other is if it makes sense for that generic power domain framework to be part of the regulator API. I do agree that separating out the common bits of power domain implementation would be good, my concerns here are around the level of integration with the regulator API. -- 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: Linus WALLEIJ on 17 May 2010 17:50 [Mark] > I do agree that separating out the common bits of power > domain implementation would be good, my concerns here are around the > level of integration with the regulator API. The plenty talk about power domains in Documentation/power/regulators/overview.txt was what got us started in this regulator direction from the beginning. Anyhow: it will certainly be closely related even if we come up with some different API for power domains so we're in the right forum. Linus
From: Mark Brown on 17 May 2010 18:20
On Mon, 2010-05-17 at 23:46 +0200, Linus WALLEIJ wrote: > [Mark] > > I do agree that separating out the common bits of power > > domain implementation would be good, my concerns here are around the > > level of integration with the regulator API. > The plenty talk about power domains in > Documentation/power/regulators/overview.txt > was what got us started in this regulator direction from the > beginning. 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. -- 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/ |