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

[Stephen Warren]

On 07/31/2016 07:01 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 25 July 2016 at 10:50, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 07/24/2016 08:07 PM, Simon Glass wrote:
>>>
>>> Hi Stephen,
>>>
>>> On 14 July 2016 at 22:17, Simon Glass <sjg at chromium.org> wrote:
>>>>
>>>> Hi Stephen,
>>>>
>>>> On 13 July 2016 at 13:45, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>>>
>>>>> From: Stephen Warren <swarren at 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 at 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 at 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.
>
> Option 'b' sounds good. I notice with regulators that there is an
> extra name in the DT (regulator-name). This is used by the 'pmic'
> command. Should power domains have that too?

The DT bindings for power domains don't have a name, no.

The problem-domain and hence DT bindings for power domains are simpler 
than those for regulators. Regulators typically need a bunch of 
configuration and hence each have their own node that describes all kind 
of metadata and configuration for the regulator. Power domains are just 
identified by a (series of) number(s), and are assumed to be very simple 
on/off objects.