On Mon, May 17, 2010 at 8:03 PM, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > On Mon, May 17, 2010 at 07:03:57PM +0530, Sundar wrote: > > There's two problems I see. One is expressing the operating modes in a > way that is suitably abstract and will work for more than one chip. Okay. > other is that as soon as the regulator driver has to know something > about the consumers you're running into trouble. > > The major goal of the regulator API is to allow us to match up consumer > drivers with regulator drivers without having any device specific tie > between the two. Pushing things that need such tie in through the API > breaks that. > Aren't machine constraints, setting maximum current limit based on total loads similar to primitive tie ups between devices and regulator driver? > Are you sure about these statements? Bear in mind that with a regulator > on a separate device there is no direct way for the regulator to know > anything about what the device it is supplying is doing, and not only > are latency requirements for mode changes are very tight but there may > not be any software running when the mode changes which is in a position > to relay information to the regulator. The trend with regulators > appears to be rather more towards removal of user visible control of the > internal operating modes of the regulator itself with the device > reconfiguring itself based on the ability to achieve good regulation at > a given load point. This gives good responsivness and efficiency over > the full range of loads. I am still confused about the knowledge of regulator about its consumer. How I see is, with the added controls, it is still devoid of any information about its clients. All that a regulator still would know is if at all there are any clients which require it at full load. I think the function *set_optimal_load is very similar to a OPP control mechanism. Instead of summing up load currents, now there are constraints. Probably you may look at the patch set at the end of this mail and comment. > have various power modes doesn't impact on the regulator except in that > it may be able to get some information about the range of currents being > supplied. The converse also applies - the consumer doesn't really need > to know anything about what the regulator is up to internally. IMO, this leads to a more decisive control over what state the regulator *can* be in; without affecting any child clients. > The big difference is that the on-SoC power domain configuration does > frequently rely on an abstraction other than the simple voltage plus > load one that the regulator API represents, as I said this frequently which is what I see as that can be bridged down. > includes a strong tie in with information about the device clocking. > Typically changing the operating mode will change or limit the clock > rates in use in various parts of the device. cannot these be handled with existing/new notifiers in place? Regards, Sundar P.S : Let me post out the patch set following on. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
