Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
On 3 April 2014 14:30, Tomasz Figa wrote: > Hi Ulf, > > > On 03.04.2014 14:16, Ulf Hansson wrote: >> >> On 3 March 2014 17:02, Tomasz Figa wrote: >>> >>> This patch introduces generic code to perform power domain look-up using >>> device tree and automatically bind devices to their power domains. >>> Generic device tree binding is introduced to specify power domains of >>> devices in their device tree nodes. >>> >>> Backwards compatibility with legacy Samsung-specific power domain >>> bindings is provided, but for now the new code is not compiled when >>> CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This >>> will change as soon as Exynos power domain code gets converted to use >>> the generic framework in further patch. >>> >>> Signed-off-by: Tomasz Figa >>> --- >>> .../devicetree/bindings/power/power_domain.txt | 51 >>> drivers/base/power/domain.c| 298 >>> + >>> include/linux/pm_domain.h | 46 >>> kernel/power/Kconfig | 4 + >>> 4 files changed, 399 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/power/power_domain.txt >>> >>> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt >>> b/Documentation/devicetree/bindings/power/power_domain.txt >>> new file mode 100644 >>> index 000..93be5d9 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/power/power_domain.txt >>> @@ -0,0 +1,51 @@ >>> +* Generic power domains >>> + >>> +System on chip designs are often divided into multiple power domains >>> that >>> +can be used for power gating of selected IP blocks for power saving by >>> +reduced leakage current. >>> + >>> +This device tree binding can be used to bind power domain consumer >>> devices >>> +with their power domains provided by power domain providers. A power >>> domain >>> +provider can be represented by any node in the device tree and can >>> provide >>> +one or more power domains. A consumer node can refer to the provider by >>> +a phandle and a set of phandle arguments (so called power domain >>> specifier) >>> +of length specified by #power-domain-cells property in the power domain >>> +provider node. >>> + >>> +==Power domain providers== >>> + >>> +Required properties: >>> + - #power-domain-cells : Number of cells in a power domain specifier; >>> + Typically 0 for nodes representing a single power domain and 1 for >>> nodes >>> + providing multiple power domains (e.g. power controllers), but can be >>> + any value as specified by device tree binding documentation of >>> particular >>> + provider. >> >> >> I am trying to understand if using a value > 1, ever would make sense. >> Wouldn't that mean each consumer (device) would actually be a part of >> more than one power domain? That won't work, right!? > > > Not exactly. Each phandle + #power-domain-cells cells are used just for > single power domain. > > The cells here are used merely as the identifier used by power domain driver > to translate a power domain specifier from DT to a kernel pointer. It's up > to driver bindings to select the number of cells to properly identify a > power domain. > > As an example (from different world, but showing the same mechanism), let's > see a common pattern of GPIO banks on some SoC: > > GPA0 > GPA1 > GPB0 > GPB1 > GPC0 > GPC1 > > One might assign a single-cell ID to each bank ending with a namespace of > integers from 0 to 5 that would be used as follows: > > #define GPA0 0 > #define GPA1 1 > #define GPB0 2 > #define GPB1 3 > #define GPC0 4 > #define GPC1 5 > > reset-gpios = < GPA0 4>; > > However one might also consider assigning one cell to bank set (e.g. GPA) > and one cell to identify the bank inside of a set, like on the following > example: > > #define GPA 0 > #define GPB 1 > #define GPC 2 > > reset-gpios = < GPA 0 4>; > > Good bindings should allow arbitrary identification schemes to let a driver > developer use the one that suits the hardware he's working on. > > >> >> Additionally, there are no corresponding parsing method (like >> of_genpd_xlate_onecell() ) that support more than one cell. > > > There are two generic xlate helpers provided for the most common cases that > are likely to be reused by most drivers. For more complex cases it's up to > the driver to implement its own mapping function. It can be promoted to a > generic one later if such need shows up. > > Best regards, > Tomasz Tomasz, thanks for the clarification! I still have more to learn about DT. :-) Not sure if some additional comments would make this more clear though - or if it's juts my untrained eye that had a few problems understanding. Kind regards Ulf Hansson -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
Hi Ulf, On 03.04.2014 14:16, Ulf Hansson wrote: On 3 March 2014 17:02, Tomasz Figa wrote: This patch introduces generic code to perform power domain look-up using device tree and automatically bind devices to their power domains. Generic device tree binding is introduced to specify power domains of devices in their device tree nodes. Backwards compatibility with legacy Samsung-specific power domain bindings is provided, but for now the new code is not compiled when CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This will change as soon as Exynos power domain code gets converted to use the generic framework in further patch. Signed-off-by: Tomasz Figa --- .../devicetree/bindings/power/power_domain.txt | 51 drivers/base/power/domain.c| 298 + include/linux/pm_domain.h | 46 kernel/power/Kconfig | 4 + 4 files changed, 399 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt new file mode 100644 index 000..93be5d9 --- /dev/null +++ b/Documentation/devicetree/bindings/power/power_domain.txt @@ -0,0 +1,51 @@ +* Generic power domains + +System on chip designs are often divided into multiple power domains that +can be used for power gating of selected IP blocks for power saving by +reduced leakage current. + +This device tree binding can be used to bind power domain consumer devices +with their power domains provided by power domain providers. A power domain +provider can be represented by any node in the device tree and can provide +one or more power domains. A consumer node can refer to the provider by +a phandle and a set of phandle arguments (so called power domain specifier) +of length specified by #power-domain-cells property in the power domain +provider node. + +==Power domain providers== + +Required properties: + - #power-domain-cells : Number of cells in a power domain specifier; + Typically 0 for nodes representing a single power domain and 1 for nodes + providing multiple power domains (e.g. power controllers), but can be + any value as specified by device tree binding documentation of particular + provider. I am trying to understand if using a value > 1, ever would make sense. Wouldn't that mean each consumer (device) would actually be a part of more than one power domain? That won't work, right!? Not exactly. Each phandle + #power-domain-cells cells are used just for single power domain. The cells here are used merely as the identifier used by power domain driver to translate a power domain specifier from DT to a kernel pointer. It's up to driver bindings to select the number of cells to properly identify a power domain. As an example (from different world, but showing the same mechanism), let's see a common pattern of GPIO banks on some SoC: GPA0 GPA1 GPB0 GPB1 GPC0 GPC1 One might assign a single-cell ID to each bank ending with a namespace of integers from 0 to 5 that would be used as follows: #define GPA0 0 #define GPA1 1 #define GPB0 2 #define GPB1 3 #define GPC0 4 #define GPC1 5 reset-gpios = < GPA0 4>; However one might also consider assigning one cell to bank set (e.g. GPA) and one cell to identify the bank inside of a set, like on the following example: #define GPA 0 #define GPB 1 #define GPC 2 reset-gpios = < GPA 0 4>; Good bindings should allow arbitrary identification schemes to let a driver developer use the one that suits the hardware he's working on. Additionally, there are no corresponding parsing method (like of_genpd_xlate_onecell() ) that support more than one cell. There are two generic xlate helpers provided for the most common cases that are likely to be reused by most drivers. For more complex cases it's up to the driver to implement its own mapping function. It can be promoted to a generic one later if such need shows up. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
On 3 March 2014 17:02, Tomasz Figa wrote:
> This patch introduces generic code to perform power domain look-up using
> device tree and automatically bind devices to their power domains.
> Generic device tree binding is introduced to specify power domains of
> devices in their device tree nodes.
>
> Backwards compatibility with legacy Samsung-specific power domain
> bindings is provided, but for now the new code is not compiled when
> CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
> will change as soon as Exynos power domain code gets converted to use
> the generic framework in further patch.
>
> Signed-off-by: Tomasz Figa
> ---
> .../devicetree/bindings/power/power_domain.txt | 51
> drivers/base/power/domain.c| 298
> +
> include/linux/pm_domain.h | 46
> kernel/power/Kconfig | 4 +
> 4 files changed, 399 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
>
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
> b/Documentation/devicetree/bindings/power/power_domain.txt
> new file mode 100644
> index 000..93be5d9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -0,0 +1,51 @@
> +* Generic power domains
> +
> +System on chip designs are often divided into multiple power domains that
> +can be used for power gating of selected IP blocks for power saving by
> +reduced leakage current.
> +
> +This device tree binding can be used to bind power domain consumer devices
> +with their power domains provided by power domain providers. A power domain
> +provider can be represented by any node in the device tree and can provide
> +one or more power domains. A consumer node can refer to the provider by
> +a phandle and a set of phandle arguments (so called power domain specifier)
> +of length specified by #power-domain-cells property in the power domain
> +provider node.
> +
> +==Power domain providers==
> +
> +Required properties:
> + - #power-domain-cells : Number of cells in a power domain specifier;
> + Typically 0 for nodes representing a single power domain and 1 for nodes
> + providing multiple power domains (e.g. power controllers), but can be
> + any value as specified by device tree binding documentation of particular
> + provider.
I am trying to understand if using a value > 1, ever would make sense.
Wouldn't that mean each consumer (device) would actually be a part of
more than one power domain? That won't work, right!?
Additionally, there are no corresponding parsing method (like
of_genpd_xlate_onecell() ) that support more than one cell.
Kind regards
Ulf Hansson
> +
> +Example:
> +
> + power: power-controller@1234 {
> + compatible = "foo,power-controller";
> + reg = <0x1234 0x1000>;
> + #power-domain-cells = <1>;
> + };
> +
> +The node above defines a power controller that is a power domain provider
> +and expects one cell as its phandle argument.
> +
> +==Power domain consumers==
> +
> +Required properties:
> + - power-domain : A phandle and power domain specifier as defined by bindings
> + of power controller specified by phandle.
> +
> +Example:
> +
> + leaky-device@1235 {
> + compatible = "foo,i-leak-current";
> + reg = <0x1235 0x1000>;
> + power-domain = < 0>;
> + };
> +
> +The node above defines a typical power domain consumer device, which is
> located
> +inside power domain with index 0 of power controller represented by node with
> +label "power".
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index dc127e5..006b455 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -3,12 +3,16 @@
> *
> * Copyright (C) 2011 Rafael J. Wysocki , Renesas Electronics
> Corp.
> *
> + * Support for Device Tree based power domain providers:
> + * Copyright (C) 2014 Tomasz Figa
> + *
> * This file is released under the GPLv2.
> */
>
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -2177,3 +2181,297 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
> list_add(>gpd_list_node, _list);
> mutex_unlock(_list_lock);
> }
> +
> +#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
> +/*
> + * DEVICE TREE BASED POWER DOMAIN PROVIDERS
> + *
> + * The code below implements generic device tree based power domain providers
> + * that bind device tree nodes with generic power domains registered in the
> + * system.
> + *
> + * Any driver that registers generic power domains and need to support
> binding
> + * of devices to these domains is supposed to register a power domain
> provider,
> + * which maps a power domain specifier retrieved from device tree to a power
> + * domain.
> + *
> + * Two simple mapping
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
On 3 April 2014 14:30, Tomasz Figa tomasz.f...@gmail.com wrote: Hi Ulf, On 03.04.2014 14:16, Ulf Hansson wrote: On 3 March 2014 17:02, Tomasz Figa tomasz.f...@gmail.com wrote: This patch introduces generic code to perform power domain look-up using device tree and automatically bind devices to their power domains. Generic device tree binding is introduced to specify power domains of devices in their device tree nodes. Backwards compatibility with legacy Samsung-specific power domain bindings is provided, but for now the new code is not compiled when CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This will change as soon as Exynos power domain code gets converted to use the generic framework in further patch. Signed-off-by: Tomasz Figa tomasz.f...@gmail.com --- .../devicetree/bindings/power/power_domain.txt | 51 drivers/base/power/domain.c| 298 + include/linux/pm_domain.h | 46 kernel/power/Kconfig | 4 + 4 files changed, 399 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt new file mode 100644 index 000..93be5d9 --- /dev/null +++ b/Documentation/devicetree/bindings/power/power_domain.txt @@ -0,0 +1,51 @@ +* Generic power domains + +System on chip designs are often divided into multiple power domains that +can be used for power gating of selected IP blocks for power saving by +reduced leakage current. + +This device tree binding can be used to bind power domain consumer devices +with their power domains provided by power domain providers. A power domain +provider can be represented by any node in the device tree and can provide +one or more power domains. A consumer node can refer to the provider by +a phandle and a set of phandle arguments (so called power domain specifier) +of length specified by #power-domain-cells property in the power domain +provider node. + +==Power domain providers== + +Required properties: + - #power-domain-cells : Number of cells in a power domain specifier; + Typically 0 for nodes representing a single power domain and 1 for nodes + providing multiple power domains (e.g. power controllers), but can be + any value as specified by device tree binding documentation of particular + provider. I am trying to understand if using a value 1, ever would make sense. Wouldn't that mean each consumer (device) would actually be a part of more than one power domain? That won't work, right!? Not exactly. Each phandle + #power-domain-cells cells are used just for single power domain. The cells here are used merely as the identifier used by power domain driver to translate a power domain specifier from DT to a kernel pointer. It's up to driver bindings to select the number of cells to properly identify a power domain. As an example (from different world, but showing the same mechanism), let's see a common pattern of GPIO banks on some SoC: GPA0 GPA1 GPB0 GPB1 GPC0 GPC1 One might assign a single-cell ID to each bank ending with a namespace of integers from 0 to 5 that would be used as follows: #define GPA0 0 #define GPA1 1 #define GPB0 2 #define GPB1 3 #define GPC0 4 #define GPC1 5 reset-gpios = gpio GPA0 4; However one might also consider assigning one cell to bank set (e.g. GPA) and one cell to identify the bank inside of a set, like on the following example: #define GPA 0 #define GPB 1 #define GPC 2 reset-gpios = gpio GPA 0 4; Good bindings should allow arbitrary identification schemes to let a driver developer use the one that suits the hardware he's working on. Additionally, there are no corresponding parsing method (like of_genpd_xlate_onecell() ) that support more than one cell. There are two generic xlate helpers provided for the most common cases that are likely to be reused by most drivers. For more complex cases it's up to the driver to implement its own mapping function. It can be promoted to a generic one later if such need shows up. Best regards, Tomasz Tomasz, thanks for the clarification! I still have more to learn about DT. :-) Not sure if some additional comments would make this more clear though - or if it's juts my untrained eye that had a few problems understanding. Kind regards Ulf Hansson -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
On 3 March 2014 17:02, Tomasz Figa tomasz.f...@gmail.com wrote:
This patch introduces generic code to perform power domain look-up using
device tree and automatically bind devices to their power domains.
Generic device tree binding is introduced to specify power domains of
devices in their device tree nodes.
Backwards compatibility with legacy Samsung-specific power domain
bindings is provided, but for now the new code is not compiled when
CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
will change as soon as Exynos power domain code gets converted to use
the generic framework in further patch.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
.../devicetree/bindings/power/power_domain.txt | 51
drivers/base/power/domain.c| 298
+
include/linux/pm_domain.h | 46
kernel/power/Kconfig | 4 +
4 files changed, 399 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
b/Documentation/devicetree/bindings/power/power_domain.txt
new file mode 100644
index 000..93be5d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -0,0 +1,51 @@
+* Generic power domains
+
+System on chip designs are often divided into multiple power domains that
+can be used for power gating of selected IP blocks for power saving by
+reduced leakage current.
+
+This device tree binding can be used to bind power domain consumer devices
+with their power domains provided by power domain providers. A power domain
+provider can be represented by any node in the device tree and can provide
+one or more power domains. A consumer node can refer to the provider by
+a phandle and a set of phandle arguments (so called power domain specifier)
+of length specified by #power-domain-cells property in the power domain
+provider node.
+
+==Power domain providers==
+
+Required properties:
+ - #power-domain-cells : Number of cells in a power domain specifier;
+ Typically 0 for nodes representing a single power domain and 1 for nodes
+ providing multiple power domains (e.g. power controllers), but can be
+ any value as specified by device tree binding documentation of particular
+ provider.
I am trying to understand if using a value 1, ever would make sense.
Wouldn't that mean each consumer (device) would actually be a part of
more than one power domain? That won't work, right!?
Additionally, there are no corresponding parsing method (like
of_genpd_xlate_onecell() ) that support more than one cell.
Kind regards
Ulf Hansson
+
+Example:
+
+ power: power-controller@1234 {
+ compatible = foo,power-controller;
+ reg = 0x1234 0x1000;
+ #power-domain-cells = 1;
+ };
+
+The node above defines a power controller that is a power domain provider
+and expects one cell as its phandle argument.
+
+==Power domain consumers==
+
+Required properties:
+ - power-domain : A phandle and power domain specifier as defined by bindings
+ of power controller specified by phandle.
+
+Example:
+
+ leaky-device@1235 {
+ compatible = foo,i-leak-current;
+ reg = 0x1235 0x1000;
+ power-domain = power 0;
+ };
+
+The node above defines a typical power domain consumer device, which is
located
+inside power domain with index 0 of power controller represented by node with
+label power.
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index dc127e5..006b455 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -3,12 +3,16 @@
*
* Copyright (C) 2011 Rafael J. Wysocki r...@sisk.pl, Renesas Electronics
Corp.
*
+ * Support for Device Tree based power domain providers:
+ * Copyright (C) 2014 Tomasz Figa tomasz.f...@gmail.com
+ *
* This file is released under the GPLv2.
*/
#include linux/init.h
#include linux/kernel.h
#include linux/io.h
+#include linux/platform_device.h
#include linux/pm_runtime.h
#include linux/pm_domain.h
#include linux/pm_qos.h
@@ -2177,3 +2181,297 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
list_add(genpd-gpd_list_node, gpd_list);
mutex_unlock(gpd_list_lock);
}
+
+#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
+/*
+ * DEVICE TREE BASED POWER DOMAIN PROVIDERS
+ *
+ * The code below implements generic device tree based power domain providers
+ * that bind device tree nodes with generic power domains registered in the
+ * system.
+ *
+ * Any driver that registers generic power domains and need to support
binding
+ * of devices to these domains is supposed to register a power domain
provider,
+ * which maps a power domain specifier retrieved from device
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
Hi Ulf, On 03.04.2014 14:16, Ulf Hansson wrote: On 3 March 2014 17:02, Tomasz Figa tomasz.f...@gmail.com wrote: This patch introduces generic code to perform power domain look-up using device tree and automatically bind devices to their power domains. Generic device tree binding is introduced to specify power domains of devices in their device tree nodes. Backwards compatibility with legacy Samsung-specific power domain bindings is provided, but for now the new code is not compiled when CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This will change as soon as Exynos power domain code gets converted to use the generic framework in further patch. Signed-off-by: Tomasz Figa tomasz.f...@gmail.com --- .../devicetree/bindings/power/power_domain.txt | 51 drivers/base/power/domain.c| 298 + include/linux/pm_domain.h | 46 kernel/power/Kconfig | 4 + 4 files changed, 399 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt new file mode 100644 index 000..93be5d9 --- /dev/null +++ b/Documentation/devicetree/bindings/power/power_domain.txt @@ -0,0 +1,51 @@ +* Generic power domains + +System on chip designs are often divided into multiple power domains that +can be used for power gating of selected IP blocks for power saving by +reduced leakage current. + +This device tree binding can be used to bind power domain consumer devices +with their power domains provided by power domain providers. A power domain +provider can be represented by any node in the device tree and can provide +one or more power domains. A consumer node can refer to the provider by +a phandle and a set of phandle arguments (so called power domain specifier) +of length specified by #power-domain-cells property in the power domain +provider node. + +==Power domain providers== + +Required properties: + - #power-domain-cells : Number of cells in a power domain specifier; + Typically 0 for nodes representing a single power domain and 1 for nodes + providing multiple power domains (e.g. power controllers), but can be + any value as specified by device tree binding documentation of particular + provider. I am trying to understand if using a value 1, ever would make sense. Wouldn't that mean each consumer (device) would actually be a part of more than one power domain? That won't work, right!? Not exactly. Each phandle + #power-domain-cells cells are used just for single power domain. The cells here are used merely as the identifier used by power domain driver to translate a power domain specifier from DT to a kernel pointer. It's up to driver bindings to select the number of cells to properly identify a power domain. As an example (from different world, but showing the same mechanism), let's see a common pattern of GPIO banks on some SoC: GPA0 GPA1 GPB0 GPB1 GPC0 GPC1 One might assign a single-cell ID to each bank ending with a namespace of integers from 0 to 5 that would be used as follows: #define GPA0 0 #define GPA1 1 #define GPB0 2 #define GPB1 3 #define GPC0 4 #define GPC1 5 reset-gpios = gpio GPA0 4; However one might also consider assigning one cell to bank set (e.g. GPA) and one cell to identify the bank inside of a set, like on the following example: #define GPA 0 #define GPB 1 #define GPC 2 reset-gpios = gpio GPA 0 4; Good bindings should allow arbitrary identification schemes to let a driver developer use the one that suits the hardware he's working on. Additionally, there are no corresponding parsing method (like of_genpd_xlate_onecell() ) that support more than one cell. There are two generic xlate helpers provided for the most common cases that are likely to be reused by most drivers. For more complex cases it's up to the driver to implement its own mapping function. It can be promoted to a generic one later if such need shows up. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
Hi Sören,
On 20.03.2014 00:13, Sören Brinkmann wrote:
On Mon, 2014-03-03 at 05:02PM +0100, Tomasz Figa wrote:
This patch introduces generic code to perform power domain look-up using
device tree and automatically bind devices to their power domains.
Generic device tree binding is introduced to specify power domains of
devices in their device tree nodes.
Backwards compatibility with legacy Samsung-specific power domain
bindings is provided, but for now the new code is not compiled when
CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
will change as soon as Exynos power domain code gets converted to use
the generic framework in further patch.
Signed-off-by: Tomasz Figa
---
.../devicetree/bindings/power/power_domain.txt | 51
drivers/base/power/domain.c| 298 +
include/linux/pm_domain.h | 46
kernel/power/Kconfig | 4 +
4 files changed, 399 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
b/Documentation/devicetree/bindings/power/power_domain.txt
new file mode 100644
index 000..93be5d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -0,0 +1,51 @@
+* Generic power domains
+
+System on chip designs are often divided into multiple power domains that
+can be used for power gating of selected IP blocks for power saving by
+reduced leakage current.
+
+This device tree binding can be used to bind power domain consumer devices
+with their power domains provided by power domain providers. A power domain
+provider can be represented by any node in the device tree and can provide
+one or more power domains. A consumer node can refer to the provider by
+a phandle and a set of phandle arguments (so called power domain specifier)
+of length specified by #power-domain-cells property in the power domain
+provider node.
+
+==Power domain providers==
+
+Required properties:
+ - #power-domain-cells : Number of cells in a power domain specifier;
+ Typically 0 for nodes representing a single power domain and 1 for nodes
+ providing multiple power domains (e.g. power controllers), but can be
+ any value as specified by device tree binding documentation of particular
+ provider.
+
+Example:
+
+ power: power-controller@1234 {
+ compatible = "foo,power-controller";
+ reg = <0x1234 0x1000>;
+ #power-domain-cells = <1>;
+ };
+
+The node above defines a power controller that is a power domain provider
+and expects one cell as its phandle argument.
+
+==Power domain consumers==
+
+Required properties:
+ - power-domain : A phandle and power domain specifier as defined by bindings
+ of power controller specified by phandle.
+
+Example:
+
+ leaky-device@1235 {
+ compatible = "foo,i-leak-current";
+ reg = <0x1235 0x1000>;
+ power-domain = < 0>;
+ };
+
+The node above defines a typical power domain consumer device, which is located
+inside power domain with index 0 of power controller represented by node with
+label "power".
Does this allow nesting of power domains? E.g. you have a PD which is
represented by some programmable power supply, and within this domain
smaller islands/domains that can be gated independently.
These are client-side bindings only, i.e. power domain providers and
consumers. Registering power domains and relations between them are up
to platform-specific code, e.g. power controller driver.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
On Mon, 2014-03-03 at 05:02PM +0100, Tomasz Figa wrote:
> This patch introduces generic code to perform power domain look-up using
> device tree and automatically bind devices to their power domains.
> Generic device tree binding is introduced to specify power domains of
> devices in their device tree nodes.
>
> Backwards compatibility with legacy Samsung-specific power domain
> bindings is provided, but for now the new code is not compiled when
> CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
> will change as soon as Exynos power domain code gets converted to use
> the generic framework in further patch.
>
> Signed-off-by: Tomasz Figa
> ---
> .../devicetree/bindings/power/power_domain.txt | 51
> drivers/base/power/domain.c| 298
> +
> include/linux/pm_domain.h | 46
> kernel/power/Kconfig | 4 +
> 4 files changed, 399 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
>
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
> b/Documentation/devicetree/bindings/power/power_domain.txt
> new file mode 100644
> index 000..93be5d9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -0,0 +1,51 @@
> +* Generic power domains
> +
> +System on chip designs are often divided into multiple power domains that
> +can be used for power gating of selected IP blocks for power saving by
> +reduced leakage current.
> +
> +This device tree binding can be used to bind power domain consumer devices
> +with their power domains provided by power domain providers. A power domain
> +provider can be represented by any node in the device tree and can provide
> +one or more power domains. A consumer node can refer to the provider by
> +a phandle and a set of phandle arguments (so called power domain specifier)
> +of length specified by #power-domain-cells property in the power domain
> +provider node.
> +
> +==Power domain providers==
> +
> +Required properties:
> + - #power-domain-cells : Number of cells in a power domain specifier;
> + Typically 0 for nodes representing a single power domain and 1 for nodes
> + providing multiple power domains (e.g. power controllers), but can be
> + any value as specified by device tree binding documentation of particular
> + provider.
> +
> +Example:
> +
> + power: power-controller@1234 {
> + compatible = "foo,power-controller";
> + reg = <0x1234 0x1000>;
> + #power-domain-cells = <1>;
> + };
> +
> +The node above defines a power controller that is a power domain provider
> +and expects one cell as its phandle argument.
> +
> +==Power domain consumers==
> +
> +Required properties:
> + - power-domain : A phandle and power domain specifier as defined by bindings
> + of power controller specified by phandle.
> +
> +Example:
> +
> + leaky-device@1235 {
> + compatible = "foo,i-leak-current";
> + reg = <0x1235 0x1000>;
> + power-domain = < 0>;
> + };
> +
> +The node above defines a typical power domain consumer device, which is
> located
> +inside power domain with index 0 of power controller represented by node with
> +label "power".
Does this allow nesting of power domains? E.g. you have a PD which is
represented by some programmable power supply, and within this domain
smaller islands/domains that can be gated independently.
Thanks,
Sören
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
On Mon, 2014-03-03 at 05:02PM +0100, Tomasz Figa wrote:
This patch introduces generic code to perform power domain look-up using
device tree and automatically bind devices to their power domains.
Generic device tree binding is introduced to specify power domains of
devices in their device tree nodes.
Backwards compatibility with legacy Samsung-specific power domain
bindings is provided, but for now the new code is not compiled when
CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
will change as soon as Exynos power domain code gets converted to use
the generic framework in further patch.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
.../devicetree/bindings/power/power_domain.txt | 51
drivers/base/power/domain.c| 298
+
include/linux/pm_domain.h | 46
kernel/power/Kconfig | 4 +
4 files changed, 399 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
b/Documentation/devicetree/bindings/power/power_domain.txt
new file mode 100644
index 000..93be5d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -0,0 +1,51 @@
+* Generic power domains
+
+System on chip designs are often divided into multiple power domains that
+can be used for power gating of selected IP blocks for power saving by
+reduced leakage current.
+
+This device tree binding can be used to bind power domain consumer devices
+with their power domains provided by power domain providers. A power domain
+provider can be represented by any node in the device tree and can provide
+one or more power domains. A consumer node can refer to the provider by
+a phandle and a set of phandle arguments (so called power domain specifier)
+of length specified by #power-domain-cells property in the power domain
+provider node.
+
+==Power domain providers==
+
+Required properties:
+ - #power-domain-cells : Number of cells in a power domain specifier;
+ Typically 0 for nodes representing a single power domain and 1 for nodes
+ providing multiple power domains (e.g. power controllers), but can be
+ any value as specified by device tree binding documentation of particular
+ provider.
+
+Example:
+
+ power: power-controller@1234 {
+ compatible = foo,power-controller;
+ reg = 0x1234 0x1000;
+ #power-domain-cells = 1;
+ };
+
+The node above defines a power controller that is a power domain provider
+and expects one cell as its phandle argument.
+
+==Power domain consumers==
+
+Required properties:
+ - power-domain : A phandle and power domain specifier as defined by bindings
+ of power controller specified by phandle.
+
+Example:
+
+ leaky-device@1235 {
+ compatible = foo,i-leak-current;
+ reg = 0x1235 0x1000;
+ power-domain = power 0;
+ };
+
+The node above defines a typical power domain consumer device, which is
located
+inside power domain with index 0 of power controller represented by node with
+label power.
Does this allow nesting of power domains? E.g. you have a PD which is
represented by some programmable power supply, and within this domain
smaller islands/domains that can be gated independently.
Thanks,
Sören
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
Hi Sören,
On 20.03.2014 00:13, Sören Brinkmann wrote:
On Mon, 2014-03-03 at 05:02PM +0100, Tomasz Figa wrote:
This patch introduces generic code to perform power domain look-up using
device tree and automatically bind devices to their power domains.
Generic device tree binding is introduced to specify power domains of
devices in their device tree nodes.
Backwards compatibility with legacy Samsung-specific power domain
bindings is provided, but for now the new code is not compiled when
CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
will change as soon as Exynos power domain code gets converted to use
the generic framework in further patch.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
.../devicetree/bindings/power/power_domain.txt | 51
drivers/base/power/domain.c| 298 +
include/linux/pm_domain.h | 46
kernel/power/Kconfig | 4 +
4 files changed, 399 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
b/Documentation/devicetree/bindings/power/power_domain.txt
new file mode 100644
index 000..93be5d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -0,0 +1,51 @@
+* Generic power domains
+
+System on chip designs are often divided into multiple power domains that
+can be used for power gating of selected IP blocks for power saving by
+reduced leakage current.
+
+This device tree binding can be used to bind power domain consumer devices
+with their power domains provided by power domain providers. A power domain
+provider can be represented by any node in the device tree and can provide
+one or more power domains. A consumer node can refer to the provider by
+a phandle and a set of phandle arguments (so called power domain specifier)
+of length specified by #power-domain-cells property in the power domain
+provider node.
+
+==Power domain providers==
+
+Required properties:
+ - #power-domain-cells : Number of cells in a power domain specifier;
+ Typically 0 for nodes representing a single power domain and 1 for nodes
+ providing multiple power domains (e.g. power controllers), but can be
+ any value as specified by device tree binding documentation of particular
+ provider.
+
+Example:
+
+ power: power-controller@1234 {
+ compatible = foo,power-controller;
+ reg = 0x1234 0x1000;
+ #power-domain-cells = 1;
+ };
+
+The node above defines a power controller that is a power domain provider
+and expects one cell as its phandle argument.
+
+==Power domain consumers==
+
+Required properties:
+ - power-domain : A phandle and power domain specifier as defined by bindings
+ of power controller specified by phandle.
+
+Example:
+
+ leaky-device@1235 {
+ compatible = foo,i-leak-current;
+ reg = 0x1235 0x1000;
+ power-domain = power 0;
+ };
+
+The node above defines a typical power domain consumer device, which is located
+inside power domain with index 0 of power controller represented by node with
+label power.
Does this allow nesting of power domains? E.g. you have a PD which is
represented by some programmable power supply, and within this domain
smaller islands/domains that can be gated independently.
These are client-side bindings only, i.e. power domain providers and
consumers. Registering power domains and relations between them are up
to platform-specific code, e.g. power controller driver.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
Tomasz Figa writes:
> This patch introduces generic code to perform power domain look-up using
> device tree and automatically bind devices to their power domains.
> Generic device tree binding is introduced to specify power domains of
> devices in their device tree nodes.
>
> Backwards compatibility with legacy Samsung-specific power domain
> bindings is provided, but for now the new code is not compiled when
> CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
> will change as soon as Exynos power domain code gets converted to use
> the generic framework in further patch.
>
> Signed-off-by: Tomasz Figa
Reviewed-by: Kevin Hilman
The approach and binding both look good to me, other than a few minor
nits on comments and question on the locking below...
[...]
> @@ -2177,3 +2181,297 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
> list_add(>gpd_list_node, _list);
> mutex_unlock(_list_lock);
> }
> +
> +#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
> +/*
> + * DEVICE TREE BASED POWER DOMAIN PROVIDERS
why all caps?
[...]
> +/* See of_genpd_get_from_provider(). */
> +static struct generic_pm_domain *__of_genpd_get_from_provider(
> + struct of_phandle_args *genpdspec)
> +{
> + struct of_genpd_provider *provider;
> + struct generic_pm_domain *genpd = ERR_PTR(-EPROBE_DEFER);
> +
> + /* Check if we have such a provider in our array */
I think you want to take the mutex here...
> + list_for_each_entry(provider, _genpd_providers, link) {
> + if (provider->node == genpdspec->np)
> + genpd = provider->xlate(genpdspec, provider->data);
> + if (!IS_ERR(genpd))
> + break;
> + }
...and release it here, right?
[...]
> +/*
> + * DEVICE<->DOMAIN BINDING USING DEVICE TREE LOOK-UP
hmm, more yelling?
Otherwise, looks good to me.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
Tomasz Figa tomasz.f...@gmail.com writes:
This patch introduces generic code to perform power domain look-up using
device tree and automatically bind devices to their power domains.
Generic device tree binding is introduced to specify power domains of
devices in their device tree nodes.
Backwards compatibility with legacy Samsung-specific power domain
bindings is provided, but for now the new code is not compiled when
CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
will change as soon as Exynos power domain code gets converted to use
the generic framework in further patch.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
Reviewed-by: Kevin Hilman khil...@linaro.org
The approach and binding both look good to me, other than a few minor
nits on comments and question on the locking below...
[...]
@@ -2177,3 +2181,297 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
list_add(genpd-gpd_list_node, gpd_list);
mutex_unlock(gpd_list_lock);
}
+
+#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
+/*
+ * DEVICE TREE BASED POWER DOMAIN PROVIDERS
why all caps?
[...]
+/* See of_genpd_get_from_provider(). */
+static struct generic_pm_domain *__of_genpd_get_from_provider(
+ struct of_phandle_args *genpdspec)
+{
+ struct of_genpd_provider *provider;
+ struct generic_pm_domain *genpd = ERR_PTR(-EPROBE_DEFER);
+
+ /* Check if we have such a provider in our array */
I think you want to take the mutex here...
+ list_for_each_entry(provider, of_genpd_providers, link) {
+ if (provider-node == genpdspec-np)
+ genpd = provider-xlate(genpdspec, provider-data);
+ if (!IS_ERR(genpd))
+ break;
+ }
...and release it here, right?
[...]
+/*
+ * DEVICE-DOMAIN BINDING USING DEVICE TREE LOOK-UP
hmm, more yelling?
Otherwise, looks good to me.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
On 05.03.2014 12:47, Tomasz Figa wrote:
Hi Ulf,
On 05.03.2014 08:19, Ulf Hansson wrote:
@@ -2177,3 +2181,297 @@ void pm_genpd_init(struct generic_pm_domain
*genpd,
list_add(>gpd_list_node, _list);
mutex_unlock(_list_lock);
}
+
+#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
Do we need a new config for this? Can't we just use CONFIG_OF?
I guess we could, but initially it would have to be CONFIG_OF &&
!CONFIG_ARCH_EXYNOS until patch 03/11 converts Exynos to use the common
code.
+ if (ret < 0) {
+ dev_err(dev, "failed to add to power domain %s: %d",
+ pd->name, ret);
+ return ret;
+ }
+
+ pm_genpd_dev_need_restore(dev, true);
So this will reflect the device as being inactive, which I think is
the wrong approach.
Usually we should expect drivers that's being probed successfully to
leave their devices in active state, right?
It depends on domain power state, but actually it seems to be already
handled in __pm_genpd_add_device(), so this line might be not needed
indeed.
Strangely enough, it seemed to be needed on Exynos for correct
operation, but maybe in the meantime some fixes in genpd code showed up.
This will need some extra testing.
Hmm, after removing this line, power domains no longer work correctly on
Exynos (thanks Marek for testing). Unfortunately I'm on a sick leave
right now and I won't be able to debug this issue on Exynos for some
time, but I'll see if I can reproduce it on s3c64xx board I have here at
home.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
On 04.03.2014 19:23, Stephen Boyd wrote: On 03/03, Tomasz Figa wrote: diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c index dc127e5..006b455 100644 --- a/drivers/base/power/domain.c +++ b/drivers/base/power/domain.c @@ -3,12 +3,16 @@ * * Copyright (C) 2011 Rafael J. Wysocki , Renesas Electronics Corp. * + * Support for Device Tree based power domain providers: + * Copyright (C) 2014 Tomasz Figa + * * This file is released under the GPLv2. */ #include #include #include +#include Is this still needed? Probably not. #include #include #include [...] + +/* + * DEVICE<->DOMAIN BINDING USING DEVICE TREE LOOK-UP + * + * The code below registers a notifier for platform bus devices' + * BUS_NOTIFY_BIND_DRIVER events and tries to attach devices to their power + * domains by looking them up using Device Tree. + * + * Similarly in BUS_NOTIFY_UNBOUND_DRIVER the device is detached from its + * domain, since it no longer supports runtime PM without any driver bound + * to it. This looks outdated. Oops, missed this one. Thanks for pointing out. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
Hi Ulf,
On 05.03.2014 08:19, Ulf Hansson wrote:
@@ -2177,3 +2181,297 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
list_add(>gpd_list_node, _list);
mutex_unlock(_list_lock);
}
+
+#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
Do we need a new config for this? Can't we just use CONFIG_OF?
I guess we could, but initially it would have to be CONFIG_OF &&
!CONFIG_ARCH_EXYNOS until patch 03/11 converts Exynos to use the common
code.
+ if (ret < 0) {
+ dev_err(dev, "failed to add to power domain %s: %d",
+ pd->name, ret);
+ return ret;
+ }
+
+ pm_genpd_dev_need_restore(dev, true);
So this will reflect the device as being inactive, which I think is
the wrong approach.
Usually we should expect drivers that's being probed successfully to
leave their devices in active state, right?
It depends on domain power state, but actually it seems to be already
handled in __pm_genpd_add_device(), so this line might be not needed indeed.
Strangely enough, it seemed to be needed on Exynos for correct
operation, but maybe in the meantime some fixes in genpd code showed up.
This will need some extra testing.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
Hi Ulf,
On 05.03.2014 08:19, Ulf Hansson wrote:
@@ -2177,3 +2181,297 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
list_add(genpd-gpd_list_node, gpd_list);
mutex_unlock(gpd_list_lock);
}
+
+#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
Do we need a new config for this? Can't we just use CONFIG_OF?
I guess we could, but initially it would have to be CONFIG_OF
!CONFIG_ARCH_EXYNOS until patch 03/11 converts Exynos to use the common
code.
+ if (ret 0) {
+ dev_err(dev, failed to add to power domain %s: %d,
+ pd-name, ret);
+ return ret;
+ }
+
+ pm_genpd_dev_need_restore(dev, true);
So this will reflect the device as being inactive, which I think is
the wrong approach.
Usually we should expect drivers that's being probed successfully to
leave their devices in active state, right?
It depends on domain power state, but actually it seems to be already
handled in __pm_genpd_add_device(), so this line might be not needed indeed.
Strangely enough, it seemed to be needed on Exynos for correct
operation, but maybe in the meantime some fixes in genpd code showed up.
This will need some extra testing.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
On 04.03.2014 19:23, Stephen Boyd wrote: On 03/03, Tomasz Figa wrote: diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c index dc127e5..006b455 100644 --- a/drivers/base/power/domain.c +++ b/drivers/base/power/domain.c @@ -3,12 +3,16 @@ * * Copyright (C) 2011 Rafael J. Wysocki r...@sisk.pl, Renesas Electronics Corp. * + * Support for Device Tree based power domain providers: + * Copyright (C) 2014 Tomasz Figa tomasz.f...@gmail.com + * * This file is released under the GPLv2. */ #include linux/init.h #include linux/kernel.h #include linux/io.h +#include linux/platform_device.h Is this still needed? Probably not. #include linux/pm_runtime.h #include linux/pm_domain.h #include linux/pm_qos.h [...] + +/* + * DEVICE-DOMAIN BINDING USING DEVICE TREE LOOK-UP + * + * The code below registers a notifier for platform bus devices' + * BUS_NOTIFY_BIND_DRIVER events and tries to attach devices to their power + * domains by looking them up using Device Tree. + * + * Similarly in BUS_NOTIFY_UNBOUND_DRIVER the device is detached from its + * domain, since it no longer supports runtime PM without any driver bound + * to it. This looks outdated. Oops, missed this one. Thanks for pointing out. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
On 05.03.2014 12:47, Tomasz Figa wrote:
Hi Ulf,
On 05.03.2014 08:19, Ulf Hansson wrote:
@@ -2177,3 +2181,297 @@ void pm_genpd_init(struct generic_pm_domain
*genpd,
list_add(genpd-gpd_list_node, gpd_list);
mutex_unlock(gpd_list_lock);
}
+
+#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
Do we need a new config for this? Can't we just use CONFIG_OF?
I guess we could, but initially it would have to be CONFIG_OF
!CONFIG_ARCH_EXYNOS until patch 03/11 converts Exynos to use the common
code.
+ if (ret 0) {
+ dev_err(dev, failed to add to power domain %s: %d,
+ pd-name, ret);
+ return ret;
+ }
+
+ pm_genpd_dev_need_restore(dev, true);
So this will reflect the device as being inactive, which I think is
the wrong approach.
Usually we should expect drivers that's being probed successfully to
leave their devices in active state, right?
It depends on domain power state, but actually it seems to be already
handled in __pm_genpd_add_device(), so this line might be not needed
indeed.
Strangely enough, it seemed to be needed on Exynos for correct
operation, but maybe in the meantime some fixes in genpd code showed up.
This will need some extra testing.
Hmm, after removing this line, power domains no longer work correctly on
Exynos (thanks Marek for testing). Unfortunately I'm on a sick leave
right now and I won't be able to debug this issue on Exynos for some
time, but I'll see if I can reproduce it on s3c64xx board I have here at
home.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
On 3 March 2014 17:02, Tomasz Figa wrote:
> This patch introduces generic code to perform power domain look-up using
> device tree and automatically bind devices to their power domains.
> Generic device tree binding is introduced to specify power domains of
> devices in their device tree nodes.
>
> Backwards compatibility with legacy Samsung-specific power domain
> bindings is provided, but for now the new code is not compiled when
> CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
> will change as soon as Exynos power domain code gets converted to use
> the generic framework in further patch.
>
> Signed-off-by: Tomasz Figa
> ---
> .../devicetree/bindings/power/power_domain.txt | 51
> drivers/base/power/domain.c| 298
> +
> include/linux/pm_domain.h | 46
> kernel/power/Kconfig | 4 +
> 4 files changed, 399 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
>
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
> b/Documentation/devicetree/bindings/power/power_domain.txt
> new file mode 100644
> index 000..93be5d9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -0,0 +1,51 @@
> +* Generic power domains
> +
> +System on chip designs are often divided into multiple power domains that
> +can be used for power gating of selected IP blocks for power saving by
> +reduced leakage current.
> +
> +This device tree binding can be used to bind power domain consumer devices
> +with their power domains provided by power domain providers. A power domain
> +provider can be represented by any node in the device tree and can provide
> +one or more power domains. A consumer node can refer to the provider by
> +a phandle and a set of phandle arguments (so called power domain specifier)
> +of length specified by #power-domain-cells property in the power domain
> +provider node.
> +
> +==Power domain providers==
> +
> +Required properties:
> + - #power-domain-cells : Number of cells in a power domain specifier;
> + Typically 0 for nodes representing a single power domain and 1 for nodes
> + providing multiple power domains (e.g. power controllers), but can be
> + any value as specified by device tree binding documentation of particular
> + provider.
> +
> +Example:
> +
> + power: power-controller@1234 {
> + compatible = "foo,power-controller";
> + reg = <0x1234 0x1000>;
> + #power-domain-cells = <1>;
> + };
> +
> +The node above defines a power controller that is a power domain provider
> +and expects one cell as its phandle argument.
> +
> +==Power domain consumers==
> +
> +Required properties:
> + - power-domain : A phandle and power domain specifier as defined by bindings
> + of power controller specified by phandle.
> +
> +Example:
> +
> + leaky-device@1235 {
> + compatible = "foo,i-leak-current";
> + reg = <0x1235 0x1000>;
> + power-domain = < 0>;
> + };
> +
> +The node above defines a typical power domain consumer device, which is
> located
> +inside power domain with index 0 of power controller represented by node with
> +label "power".
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index dc127e5..006b455 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -3,12 +3,16 @@
> *
> * Copyright (C) 2011 Rafael J. Wysocki , Renesas Electronics
> Corp.
> *
> + * Support for Device Tree based power domain providers:
> + * Copyright (C) 2014 Tomasz Figa
> + *
> * This file is released under the GPLv2.
> */
>
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -2177,3 +2181,297 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
> list_add(>gpd_list_node, _list);
> mutex_unlock(_list_lock);
> }
> +
> +#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
Do we need a new config for this? Can't we just use CONFIG_OF?
> +/*
> + * DEVICE TREE BASED POWER DOMAIN PROVIDERS
> + *
> + * The code below implements generic device tree based power domain providers
> + * that bind device tree nodes with generic power domains registered in the
> + * system.
> + *
> + * Any driver that registers generic power domains and need to support
> binding
> + * of devices to these domains is supposed to register a power domain
> provider,
> + * which maps a power domain specifier retrieved from device tree to a power
> + * domain.
> + *
> + * Two simple mapping functions have been provided for convenience:
> + * - of_genpd_xlate_simple() for 1:1 device tree node to domain mapping,
> + * - of_genpd_xlate_onecell() for mapping of multiple domains per node
> + *by index.
> + */
> +
> +/**
> + * struct of_genpd_provider - Power domain
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
On Mon, Mar 03, 2014 at 05:02:06PM +0100, Tomasz Figa wrote: > This patch introduces generic code to perform power domain look-up using > device tree and automatically bind devices to their power domains. > Generic device tree binding is introduced to specify power domains of > devices in their device tree nodes. > > Backwards compatibility with legacy Samsung-specific power domain > bindings is provided, but for now the new code is not compiled when > CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This > will change as soon as Exynos power domain code gets converted to use > the generic framework in further patch. Reviwed-by: Mark Brown (mainly the binding) signature.asc Description: Digital signature
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
On 03/03, Tomasz Figa wrote: > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c > index dc127e5..006b455 100644 > --- a/drivers/base/power/domain.c > +++ b/drivers/base/power/domain.c > @@ -3,12 +3,16 @@ > * > * Copyright (C) 2011 Rafael J. Wysocki , Renesas Electronics > Corp. > * > + * Support for Device Tree based power domain providers: > + * Copyright (C) 2014 Tomasz Figa > + * > * This file is released under the GPLv2. > */ > > #include > #include > #include > +#include Is this still needed? > #include > #include > #include [...] > + > +/* > + * DEVICE<->DOMAIN BINDING USING DEVICE TREE LOOK-UP > + * > + * The code below registers a notifier for platform bus devices' > + * BUS_NOTIFY_BIND_DRIVER events and tries to attach devices to their power > + * domains by looking them up using Device Tree. > + * > + * Similarly in BUS_NOTIFY_UNBOUND_DRIVER the device is detached from its > + * domain, since it no longer supports runtime PM without any driver bound > + * to it. This looks outdated. > + * > + * Both generic and legacy Samsung-specific DT bindings are supported to > + * keep backwards compatibility with existing DTBs. > + */ -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
On 03/03, Tomasz Figa wrote: diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c index dc127e5..006b455 100644 --- a/drivers/base/power/domain.c +++ b/drivers/base/power/domain.c @@ -3,12 +3,16 @@ * * Copyright (C) 2011 Rafael J. Wysocki r...@sisk.pl, Renesas Electronics Corp. * + * Support for Device Tree based power domain providers: + * Copyright (C) 2014 Tomasz Figa tomasz.f...@gmail.com + * * This file is released under the GPLv2. */ #include linux/init.h #include linux/kernel.h #include linux/io.h +#include linux/platform_device.h Is this still needed? #include linux/pm_runtime.h #include linux/pm_domain.h #include linux/pm_qos.h [...] + +/* + * DEVICE-DOMAIN BINDING USING DEVICE TREE LOOK-UP + * + * The code below registers a notifier for platform bus devices' + * BUS_NOTIFY_BIND_DRIVER events and tries to attach devices to their power + * domains by looking them up using Device Tree. + * + * Similarly in BUS_NOTIFY_UNBOUND_DRIVER the device is detached from its + * domain, since it no longer supports runtime PM without any driver bound + * to it. This looks outdated. + * + * Both generic and legacy Samsung-specific DT bindings are supported to + * keep backwards compatibility with existing DTBs. + */ -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
On Mon, Mar 03, 2014 at 05:02:06PM +0100, Tomasz Figa wrote: This patch introduces generic code to perform power domain look-up using device tree and automatically bind devices to their power domains. Generic device tree binding is introduced to specify power domains of devices in their device tree nodes. Backwards compatibility with legacy Samsung-specific power domain bindings is provided, but for now the new code is not compiled when CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This will change as soon as Exynos power domain code gets converted to use the generic framework in further patch. Reviwed-by: Mark Brown broo...@linaro.org (mainly the binding) signature.asc Description: Digital signature
Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
On 3 March 2014 17:02, Tomasz Figa tomasz.f...@gmail.com wrote:
This patch introduces generic code to perform power domain look-up using
device tree and automatically bind devices to their power domains.
Generic device tree binding is introduced to specify power domains of
devices in their device tree nodes.
Backwards compatibility with legacy Samsung-specific power domain
bindings is provided, but for now the new code is not compiled when
CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
will change as soon as Exynos power domain code gets converted to use
the generic framework in further patch.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
.../devicetree/bindings/power/power_domain.txt | 51
drivers/base/power/domain.c| 298
+
include/linux/pm_domain.h | 46
kernel/power/Kconfig | 4 +
4 files changed, 399 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
b/Documentation/devicetree/bindings/power/power_domain.txt
new file mode 100644
index 000..93be5d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -0,0 +1,51 @@
+* Generic power domains
+
+System on chip designs are often divided into multiple power domains that
+can be used for power gating of selected IP blocks for power saving by
+reduced leakage current.
+
+This device tree binding can be used to bind power domain consumer devices
+with their power domains provided by power domain providers. A power domain
+provider can be represented by any node in the device tree and can provide
+one or more power domains. A consumer node can refer to the provider by
+a phandle and a set of phandle arguments (so called power domain specifier)
+of length specified by #power-domain-cells property in the power domain
+provider node.
+
+==Power domain providers==
+
+Required properties:
+ - #power-domain-cells : Number of cells in a power domain specifier;
+ Typically 0 for nodes representing a single power domain and 1 for nodes
+ providing multiple power domains (e.g. power controllers), but can be
+ any value as specified by device tree binding documentation of particular
+ provider.
+
+Example:
+
+ power: power-controller@1234 {
+ compatible = foo,power-controller;
+ reg = 0x1234 0x1000;
+ #power-domain-cells = 1;
+ };
+
+The node above defines a power controller that is a power domain provider
+and expects one cell as its phandle argument.
+
+==Power domain consumers==
+
+Required properties:
+ - power-domain : A phandle and power domain specifier as defined by bindings
+ of power controller specified by phandle.
+
+Example:
+
+ leaky-device@1235 {
+ compatible = foo,i-leak-current;
+ reg = 0x1235 0x1000;
+ power-domain = power 0;
+ };
+
+The node above defines a typical power domain consumer device, which is
located
+inside power domain with index 0 of power controller represented by node with
+label power.
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index dc127e5..006b455 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -3,12 +3,16 @@
*
* Copyright (C) 2011 Rafael J. Wysocki r...@sisk.pl, Renesas Electronics
Corp.
*
+ * Support for Device Tree based power domain providers:
+ * Copyright (C) 2014 Tomasz Figa tomasz.f...@gmail.com
+ *
* This file is released under the GPLv2.
*/
#include linux/init.h
#include linux/kernel.h
#include linux/io.h
+#include linux/platform_device.h
#include linux/pm_runtime.h
#include linux/pm_domain.h
#include linux/pm_qos.h
@@ -2177,3 +2181,297 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
list_add(genpd-gpd_list_node, gpd_list);
mutex_unlock(gpd_list_lock);
}
+
+#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
Do we need a new config for this? Can't we just use CONFIG_OF?
+/*
+ * DEVICE TREE BASED POWER DOMAIN PROVIDERS
+ *
+ * The code below implements generic device tree based power domain providers
+ * that bind device tree nodes with generic power domains registered in the
+ * system.
+ *
+ * Any driver that registers generic power domains and need to support
binding
+ * of devices to these domains is supposed to register a power domain
provider,
+ * which maps a power domain specifier retrieved from device tree to a power
+ * domain.
+ *
+ * Two simple mapping functions have been provided for convenience:
+ * - of_genpd_xlate_simple() for 1:1 device tree node to domain mapping,
+ * - of_genpd_xlate_onecell() for mapping of multiple domains per node
+ *by index.
+ */
+
[PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
This patch introduces generic code to perform power domain look-up using
device tree and automatically bind devices to their power domains.
Generic device tree binding is introduced to specify power domains of
devices in their device tree nodes.
Backwards compatibility with legacy Samsung-specific power domain
bindings is provided, but for now the new code is not compiled when
CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
will change as soon as Exynos power domain code gets converted to use
the generic framework in further patch.
Signed-off-by: Tomasz Figa
---
.../devicetree/bindings/power/power_domain.txt | 51
drivers/base/power/domain.c| 298 +
include/linux/pm_domain.h | 46
kernel/power/Kconfig | 4 +
4 files changed, 399 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
b/Documentation/devicetree/bindings/power/power_domain.txt
new file mode 100644
index 000..93be5d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -0,0 +1,51 @@
+* Generic power domains
+
+System on chip designs are often divided into multiple power domains that
+can be used for power gating of selected IP blocks for power saving by
+reduced leakage current.
+
+This device tree binding can be used to bind power domain consumer devices
+with their power domains provided by power domain providers. A power domain
+provider can be represented by any node in the device tree and can provide
+one or more power domains. A consumer node can refer to the provider by
+a phandle and a set of phandle arguments (so called power domain specifier)
+of length specified by #power-domain-cells property in the power domain
+provider node.
+
+==Power domain providers==
+
+Required properties:
+ - #power-domain-cells : Number of cells in a power domain specifier;
+ Typically 0 for nodes representing a single power domain and 1 for nodes
+ providing multiple power domains (e.g. power controllers), but can be
+ any value as specified by device tree binding documentation of particular
+ provider.
+
+Example:
+
+ power: power-controller@1234 {
+ compatible = "foo,power-controller";
+ reg = <0x1234 0x1000>;
+ #power-domain-cells = <1>;
+ };
+
+The node above defines a power controller that is a power domain provider
+and expects one cell as its phandle argument.
+
+==Power domain consumers==
+
+Required properties:
+ - power-domain : A phandle and power domain specifier as defined by bindings
+ of power controller specified by phandle.
+
+Example:
+
+ leaky-device@1235 {
+ compatible = "foo,i-leak-current";
+ reg = <0x1235 0x1000>;
+ power-domain = < 0>;
+ };
+
+The node above defines a typical power domain consumer device, which is located
+inside power domain with index 0 of power controller represented by node with
+label "power".
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index dc127e5..006b455 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -3,12 +3,16 @@
*
* Copyright (C) 2011 Rafael J. Wysocki , Renesas Electronics
Corp.
*
+ * Support for Device Tree based power domain providers:
+ * Copyright (C) 2014 Tomasz Figa
+ *
* This file is released under the GPLv2.
*/
#include
#include
#include
+#include
#include
#include
#include
@@ -2177,3 +2181,297 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
list_add(>gpd_list_node, _list);
mutex_unlock(_list_lock);
}
+
+#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
+/*
+ * DEVICE TREE BASED POWER DOMAIN PROVIDERS
+ *
+ * The code below implements generic device tree based power domain providers
+ * that bind device tree nodes with generic power domains registered in the
+ * system.
+ *
+ * Any driver that registers generic power domains and need to support binding
+ * of devices to these domains is supposed to register a power domain provider,
+ * which maps a power domain specifier retrieved from device tree to a power
+ * domain.
+ *
+ * Two simple mapping functions have been provided for convenience:
+ * - of_genpd_xlate_simple() for 1:1 device tree node to domain mapping,
+ * - of_genpd_xlate_onecell() for mapping of multiple domains per node
+ *by index.
+ */
+
+/**
+ * struct of_genpd_provider - Power domain provider registration structure
+ * @link: Entry in global list of domain providers
+ * @node: Pointer to device tree node of domain provider
+ * @xlate: Provider-specific xlate callback mapping a set of specifier cells
+ * into a power domain.
+ * @data: context pointer to be passed into @xlate callback
+ */
+struct of_genpd_provider {
+ struct list_head
[PATCH v2 01/11] base: power: Add generic OF-based power domain look-up
This patch introduces generic code to perform power domain look-up using
device tree and automatically bind devices to their power domains.
Generic device tree binding is introduced to specify power domains of
devices in their device tree nodes.
Backwards compatibility with legacy Samsung-specific power domain
bindings is provided, but for now the new code is not compiled when
CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
will change as soon as Exynos power domain code gets converted to use
the generic framework in further patch.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
.../devicetree/bindings/power/power_domain.txt | 51
drivers/base/power/domain.c| 298 +
include/linux/pm_domain.h | 46
kernel/power/Kconfig | 4 +
4 files changed, 399 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
b/Documentation/devicetree/bindings/power/power_domain.txt
new file mode 100644
index 000..93be5d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -0,0 +1,51 @@
+* Generic power domains
+
+System on chip designs are often divided into multiple power domains that
+can be used for power gating of selected IP blocks for power saving by
+reduced leakage current.
+
+This device tree binding can be used to bind power domain consumer devices
+with their power domains provided by power domain providers. A power domain
+provider can be represented by any node in the device tree and can provide
+one or more power domains. A consumer node can refer to the provider by
+a phandle and a set of phandle arguments (so called power domain specifier)
+of length specified by #power-domain-cells property in the power domain
+provider node.
+
+==Power domain providers==
+
+Required properties:
+ - #power-domain-cells : Number of cells in a power domain specifier;
+ Typically 0 for nodes representing a single power domain and 1 for nodes
+ providing multiple power domains (e.g. power controllers), but can be
+ any value as specified by device tree binding documentation of particular
+ provider.
+
+Example:
+
+ power: power-controller@1234 {
+ compatible = foo,power-controller;
+ reg = 0x1234 0x1000;
+ #power-domain-cells = 1;
+ };
+
+The node above defines a power controller that is a power domain provider
+and expects one cell as its phandle argument.
+
+==Power domain consumers==
+
+Required properties:
+ - power-domain : A phandle and power domain specifier as defined by bindings
+ of power controller specified by phandle.
+
+Example:
+
+ leaky-device@1235 {
+ compatible = foo,i-leak-current;
+ reg = 0x1235 0x1000;
+ power-domain = power 0;
+ };
+
+The node above defines a typical power domain consumer device, which is located
+inside power domain with index 0 of power controller represented by node with
+label power.
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index dc127e5..006b455 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -3,12 +3,16 @@
*
* Copyright (C) 2011 Rafael J. Wysocki r...@sisk.pl, Renesas Electronics
Corp.
*
+ * Support for Device Tree based power domain providers:
+ * Copyright (C) 2014 Tomasz Figa tomasz.f...@gmail.com
+ *
* This file is released under the GPLv2.
*/
#include linux/init.h
#include linux/kernel.h
#include linux/io.h
+#include linux/platform_device.h
#include linux/pm_runtime.h
#include linux/pm_domain.h
#include linux/pm_qos.h
@@ -2177,3 +2181,297 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
list_add(genpd-gpd_list_node, gpd_list);
mutex_unlock(gpd_list_lock);
}
+
+#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
+/*
+ * DEVICE TREE BASED POWER DOMAIN PROVIDERS
+ *
+ * The code below implements generic device tree based power domain providers
+ * that bind device tree nodes with generic power domains registered in the
+ * system.
+ *
+ * Any driver that registers generic power domains and need to support binding
+ * of devices to these domains is supposed to register a power domain provider,
+ * which maps a power domain specifier retrieved from device tree to a power
+ * domain.
+ *
+ * Two simple mapping functions have been provided for convenience:
+ * - of_genpd_xlate_simple() for 1:1 device tree node to domain mapping,
+ * - of_genpd_xlate_onecell() for mapping of multiple domains per node
+ *by index.
+ */
+
+/**
+ * struct of_genpd_provider - Power domain provider registration structure
+ * @link: Entry in global list of domain providers
+ * @node: Pointer to device tree node of domain provider
+ * @xlate: Provider-specific xlate callback mapping a set of
