On 07/31/2016 07:01 PM, Simon Glass wrote:
Hi Stephen,
On 25 July 2016 at 10:50, Stephen Warren <swar...@wwwdotorg.org> wrote:
On 07/24/2016 08:07 PM, Simon Glass wrote:
Hi Stephen,
On 14 July 2016 at 22:17, Simon Glass <s...@chromium.org> wrote:
Hi Stephen,
On 13 July 2016 at 13:45, Stephen Warren <swar...@wwwdotorg.org> wrote:
From: Stephen Warren <swar...@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 <swar...@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 <s...@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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
