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

[Simon Glass]

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?

Regards,
Simon