Add a power domain framework/uclass
PATCH 1/1 Add a power domain framework/uclass
From: Stephen Warren <[email protected]>
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.
---
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.
Makefile | 1 + arch/sandbox/dts/test.dts | 10 ++ arch/sandbox/include/asm/power-domain.h | 21 ++++ configs/sandbox_defconfig | 2 + drivers/power/Kconfig | 2 + drivers/power/domain/Kconfig | 20 ++++ drivers/power/domain/Makefile | 7 ++ drivers/power/domain/power-domain-uclass.c | 112 +++++++++++++++++++++ drivers/power/domain/sandbox-power-domain-test.c | 55 +++++++++++ drivers/power/domain/sandbox-power-domain.c | 104 ++++++++++++++++++++ include/dm/uclass-id.h | 1 + include/power-domain-uclass.h | 82 ++++++++++++++++ include/power-domain.h | 120 +++++++++++++++++++++++ test/dm/Makefile | 1 + test/dm/power-domain.c | 46 +++++++++ 15 files changed, 584 insertions(+) create mode 100644 arch/sandbox/include/asm/power-domain.h create mode 100644 drivers/power/domain/Kconfig create mode 100644 drivers/power/domain/Makefile create mode 100644 drivers/power/domain/power-domain-uclass.c create mode 100644 drivers/power/domain/sandbox-power-domain-test.c create mode 100644 drivers/power/domain/sandbox-power-domain.c create mode 100644 include/power-domain-uclass.h create mode 100644 include/power-domain.h create mode 100644 test/dm/power-domain.c
Makefile +1 -0
@@ -637,6 +637,7 @@ libs-y += drivers/net/ libs-y += drivers/net/phy/ libs-y += drivers/pci/ libs-y += drivers/power/ \ + drivers/power/domain/ \ drivers/power/fuel_gauge/ \ drivers/power/mfd/ \ drivers/power/pmic/ \
arch/sandbox/dts/test.dts +10 -0
@@ -262,6 +262,16 @@ }; }; + pwrdom: power-domain { + compatible = "sandbox,power-domain"; + #power-domain-cells = <1>; + }; + + power-domain-test { + compatible = "sandbox,power-domain-test"; + power-domains = <&pwrdom 2>; + }; + ram { compatible = "sandbox,ram"; };
arch/sandbox/include/asm/power-domain.h new file +21 -0
@@ -0,0 +1,21 @@ +/* +* Copyright (c) 2016, NVIDIA CORPORATION. +* +* SPDX-License-Identifier: GPL-2.0 +*/ + +#ifndef __SANDBOX_POWER_DOMAIN_H +#define __SANDBOX_POWER_DOMAIN_H + +#include <common.h> + +struct udevice ; + +int sandbox_power_domain_query (struct udevice *dev,unsigned long id); + +int sandbox_power_domain_test_get (struct udevice *dev); +int sandbox_power_domain_test_on (struct udevice *dev); +int sandbox_power_domain_test_off (struct udevice *dev); +int sandbox_power_domain_test_free (struct udevice *dev); + +#endif
configs/sandbox_defconfig +2 -0
@@ -175,3 +175,5 @@ CONFIG_UNIT_TEST=y CONFIG_UT_TIME=y CONFIG_UT_DM=y CONFIG_UT_ENV=y +CONFIG_POWER_DOMAIN=y +CONFIG_SANDBOX_POWER_DOMAIN=y
drivers/power/Kconfig +2 -0
@@ -1,5 +1,7 @@ menu "Power" +source "drivers/power/domain/Kconfig" + source "drivers/power/pmic/Kconfig" source "drivers/power/regulator/Kconfig"
drivers/power/domain/Kconfig new file +20 -0
@@ -0,0 +1,20 @@ +menu "Power Domain Support" + +config POWER_DOMAIN + bool "Enable power domain support using Driver Model" + depends on DM && OF_CONTROL + help + Enable support for the power domain driver class. 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. + +config SANDBOX_POWER_DOMAIN + bool "Enable the sandbox power domain test driver" + depends on POWER_DOMAIN && SANDBOX + help + Enable support for a test power domain driver implementation, which + simply accepts requests to power on/off various HW modules without + actually doing anything beyond a little error checking. + +endmenu
drivers/power/domain/Makefile new file +7 -0
@@ -0,0 +1,7 @@ +# Copyright (c) 2016, NVIDIA CORPORATION. +# +# SPDX-License-Identifier: GPL-2.0 + +obj-$(CONFIG_POWER_DOMAIN) += power-domain-uclass.o +obj-$(CONFIG_SANDBOX_POWER_DOMAIN) += sandbox-power-domain.o +obj-$(CONFIG_SANDBOX_POWER_DOMAIN) += sandbox-power-domain-test.o
drivers/power/domain/power-domain-uclass.c new file +112 -0
112 lines not on this page · raw message
drivers/power/domain/sandbox-power-domain-test.c new file +55 -0
55 lines not on this page · raw message
drivers/power/domain/sandbox-power-domain.c new file +104 -0
104 lines not on this page · raw message
include/dm/uclass-id.h +1 -0
@@ -60,6 +60,7 @@ enum uclass_id {UCLASS_PINCONFIG ,/* Pin configuration node device */ UCLASS_PMIC ,/* PMIC I/O device */ UCLASS_PWM ,/* Pulse-width modulator */ +UCLASS_POWER_DOMAIN ,/* (SoC) Power domains */ UCLASS_PWRSEQ ,/* Power sequence device */ UCLASS_REGULATOR ,/* Regulator device */ UCLASS_REMOTEPROC, /* Remote Processor device */
include/power-domain-uclass.h new file +82 -0
82 lines not on this page · raw message
include/power-domain.h new file +120 -0
120 lines not on this page · raw message
test/dm/Makefile +1 -0
@@ -24,6 +24,7 @@ obj-$(CONFIG_LED) += led.o obj-$(CONFIG_DM_MAILBOX) += mailbox.o obj-$(CONFIG_DM_MMC) += mmc.o obj-$(CONFIG_DM_PCI) += pci.o +obj-$(CONFIG_POWER_DOMAIN) += power-domain.o obj-$(CONFIG_RAM) += ram.o obj-y += regmap.o obj-$(CONFIG_REMOTEPROC) += remoteproc.o
test/dm/power-domain.c new file +46 -0
46 lines not on this page · raw message
Signature · 1 line
2.9.1
PATCH 1/1 Add a power domain framework/uclass
Hi Stephen,
Quoted 29 lines · Stephen Warren
From: Stephen Warren <[email protected]>
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 <[email protected]>---
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.Makefile | 1 + arch/sandbox/dts/test.dts | 10 ++ arch/sandbox/include/asm/power-domain.h | 21 ++++ configs/sandbox_defconfig | 2 + drivers/power/Kconfig | 2 + drivers/power/domain/Kconfig | 20 ++++ drivers/power/domain/Makefile | 7 ++ drivers/power/domain/power-domain-uclass.c | 112 +++++++++++++++++++++ drivers/power/domain/sandbox-power-domain-test.c | 55 +++++++++++ drivers/power/domain/sandbox-power-domain.c | 104 ++++++++++++++++++++ include/dm/uclass-id.h | 1 + include/power-domain-uclass.h | 82 ++++++++++++++++ include/power-domain.h | 120 +++++++++++++++++++++++ test/dm/Makefile | 1 + test/dm/power-domain.c | 46 +++++++++ 15 files changed, 584 insertions(+) create mode 100644 arch/sandbox/include/asm/power-domain.h
Quoted 8 lines
create mode 100644 drivers/power/domain/Kconfig create mode 100644 drivers/power/domain/Makefile create mode 100644 drivers/power/domain/power-domain-uclass.c create mode 100644 drivers/power/domain/sandbox-power-domain-test.c create mode 100644 drivers/power/domain/sandbox-power-domain.c create mode 100644 include/power-domain-uclass.h create mode 100644 include/power-domain.h create mode 100644 test/dm/power-domain.c
Could you add a command (with list/on/off subcommands) to control this also?
Regards,
Simon
PATCH 1/1 Add a power domain framework/uclass
Hi Stephen,
Quoted 41 lines · Simon Glass
Hi Stephen,
Quoted 29 lines · Stephen Warren
From: Stephen Warren <[email protected]>
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 <[email protected]>---
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.Makefile | 1 + arch/sandbox/dts/test.dts | 10 ++ arch/sandbox/include/asm/power-domain.h | 21 ++++ configs/sandbox_defconfig | 2 + drivers/power/Kconfig | 2 + drivers/power/domain/Kconfig | 20 ++++ drivers/power/domain/Makefile | 7 ++ drivers/power/domain/power-domain-uclass.c | 112 +++++++++++++++++++++ drivers/power/domain/sandbox-power-domain-test.c | 55 +++++++++++ drivers/power/domain/sandbox-power-domain.c | 104 ++++++++++++++++++++ include/dm/uclass-id.h | 1 + include/power-domain-uclass.h | 82 ++++++++++++++++ include/power-domain.h | 120 +++++++++++++++++++++++ test/dm/Makefile | 1 + test/dm/power-domain.c | 46 +++++++++ 15 files changed, 584 insertions(+) create mode 100644 arch/sandbox/include/asm/power-domain.hQuoted 8 lines
create mode 100644 drivers/power/domain/Kconfig create mode 100644 drivers/power/domain/Makefile create mode 100644 drivers/power/domain/power-domain-uclass.c create mode 100644 drivers/power/domain/sandbox-power-domain-test.c create mode 100644 drivers/power/domain/sandbox-power-domain.c create mode 100644 include/power-domain-uclass.h create mode 100644 include/power-domain.h create mode 100644 test/dm/power-domain.c
Quoted 3 lines
Acked-by Simon Glass <[email protected]>Could you add a command (with list/on/off subcommands) to control this also?
Any thoughts on this?
Applied to u-boot-dm, thanks!
PATCH 1/1 Add a power domain framework/uclass
Quoted 17 lines · Simon Glass
Hi Stephen,
Quoted 14 lines · Simon Glass
Hi Stephen,
Quoted 11 lines · Stephen Warren
From: Stephen Warren <[email protected]>
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 <[email protected]>---
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.
...
Quoted 7 lines
Quoted 3 lines
Acked-by Simon Glass <[email protected]>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.
PATCH 1/1 Add a power domain framework/uclass
Hi Stephen,
Quoted 52 lines · Stephen Warren
Quoted 21 lines · Simon Glass
Hi Stephen,
Quoted 17 lines · Simon Glass
Hi Stephen,
Quoted 13 lines · Stephen Warren
From: Stephen Warren <[email protected]>
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 <[email protected]>---
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....
Quoted 10 lines
Quoted 5 lines
Acked-by Simon Glass <[email protected]>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.
Quoted 4 lines
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
PATCH 1/1 Add a power domain framework/uclass
Quoted 55 lines · Simon Glass
Hi Stephen,
Quoted 52 lines · Stephen Warren
Quoted 21 lines · Simon Glass
Hi Stephen,
Quoted 17 lines · Simon Glass
Hi Stephen,
Quoted 13 lines · Stephen Warren
From: Stephen Warren <[email protected]>
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 <[email protected]>---
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....
Quoted 10 lines
Quoted 5 lines
Acked-by Simon Glass <[email protected]>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.
Quoted 8 lines
Quoted 4 lines
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.