[U-Boot] [PATCH] Add a power domain framework/uclass

[Stephen Warren <swarren@wwwdotorg.org>]

On 07/24/2016 08:07 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 14 July 2016 at 22:17, Simon Glass <sjg@chromium.org> wrote:
>> Hi Stephen,
>>
>> On 13 July 2016 at 13:45, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>> From: Stephen Warren <swarren@nvidia.com>
>>>
>>> Many SoCs allow power to be applied to or removed from portions of the SoC
>>> (power domains). This may be used to save power. This API provides the
>>> means to control such power management hardware.
>>>
>>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>>> ---
>>> I'll soon(?) send a Tegra186 power domain driver that implements this
>>> new subsystem. I'm waiting for all the relevant DT bindings to be
>>> reviewed as kernel patches first though.
...
>> Acked-by: Simon Glass <sjg@chromium.org>
>>
>> Could you add a command (with list/on/off subcommands) to control this also?
>
> Any thoughts on this?
>
> Applied to u-boot-dm, thanks!

Such a command sounds like a good idea. I'm a bit too swamped to do this 
immediately though.

One issue to consider: How would the user specify which power domain to 
control? There's no global namespace. Only individual drivers can parse 
their own namespace, and there's no requirement that drivers identify 
each powerdomain with e.g. a single integer or name, just like DT 
specificiers can use multiple cells. I can think of two ways to handle this:

a) Add a new "op" function to the driver to allow converting the cmdline 
arguments the user passed to the shell command into whatever value(s) 
the driver uses to identify the power domain, e.g. "cmdline_xlate()". 
This has the disadvantage of requiring extra code (although we could 
provide a default implementation for the common code), but has the 
advantage of allowing control over any powerdomain that any driver 
implements.

b) Make the command take a DT property node name and index, and have the 
command look the powerdomain ID up from DT. This has the disadvantage of 
limiting control to powerdomains that are already added to the DT, but 
does have the advantage of not requiring any driver code.