On Sat, Apr 03, 2010 at 08:12:56PM +0200, Sundar R IYER wrote: Please fix your mail client to word wrap within paragraphs; not doing this makes your messages harder to read and reply to. I've reflowed below. > 1. The documentation for the regulators mentions "power domains" and > "switches" to be modeled as regulators. I am planning to model multiple > "switches" for controlling supplies to various peripherals from a main > master regulator as multiple regulators, childed from the parent > regulator. Is this the right way to proceed ahead? Further the options If you want to do this in the regulator framework, yes. > for these switches will be only a logical on/off. (BTW, I saw lots of TI > stuff which is something related to power domains, but it doesn't model > the regulator framework.) Nor does the SH stuff. With the power domains of a CPU it often doesn't buy terribly much to use the regulator framework - the power domains are often a small part of a much bigger picture for the CPU internal power management, often incorporating thing > 2. In the same example below, should I instead model just the main > regulator, and in the driver specific enable/disable, iterate through > the list of consumers, and then accordingly enable/disable these > switches according to the calling consumer?. In this way, I can choose > not to clutter those smaller switches as regulators in my regulator as > well as peripheral driver code.? I'm not entirely sure what you mean here. No regulator driver should ever have any knowledge of its consumers, this will be handled by the regulator core, and regulators should not be making decisions about their own power state - this should also be done by the core. Perhaps if you could provide a more concrete example your question might be clearer? > 3. Extending the same model, I want to use the _set_optimum API. > Logically, enabling/disabling the child supply or setting an optimal > load on the regulator must propagate the new load to any master > regulator ( which can then again be set an optimal load). My This isn't entirely clear, actually. Translating the load on a child regulator to that on a parent regulator isn't trivial since the performance of both regulators needs to be taken into consideration - the child regulator will have its own requirements for the input. These will obviously be influenced by the load it experiences but it's not as direct a mapping as is desirable for propagating up the tree in a generic fashion. > understanding of this function shows me that currently, this is not > supported in the function. Am I right in deducing this or have I failed > to overlook some other portions in the regulator code? There's no code to do this at the minute - like I say, it's not as easy as might be desirable. The other thing to bear in mind here is that hardware is making this less and less relevant. With modern regulators the regulator itself is capable of responding quickly enough to load changes to automatically switch between most if not all of the operating modes without software intervention. This means that managing the mode in software generally ends up being less efficient than just leaving the hardware to it. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
