diff mbox

[RFC,v2,08/12] soc: samsung: pm_domain: Add support for parent power domain

Message ID 1416834256-11225-8-git-send-email-amit.daniel@samsung.com (mailing list archive)
State RFC, archived
Headers show

Commit Message

Amit Kachhap Nov. 24, 2014, 1:04 p.m. UTC
This patch adds supports for parent power domain. This will ensure
invoking of parent/child power domain on/off in a correct sequence.
In exynos7 SOC's, power domain controllers have parent and child
hierarchy.

Cc: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
---
 .../bindings/arm/exynos/power_domain.txt           |    2 +
 drivers/soc/samsung/pm_domains.c                   |   43 +++++++++++++++++++-
 2 files changed, 44 insertions(+), 1 deletion(-)

Comments

Ulf Hansson Nov. 25, 2014, 7:59 a.m. UTC | #1
On 24 November 2014 at 14:04, Amit Daniel Kachhap
<amit.daniel@samsung.com> wrote:
> This patch adds supports for parent power domain. This will ensure
> invoking of parent/child power domain on/off in a correct sequence.
> In exynos7 SOC's, power domain controllers have parent and child
> hierarchy.
>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
> Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
> ---
>  .../bindings/arm/exynos/power_domain.txt           |    2 +
>  drivers/soc/samsung/pm_domains.c                   |   43 +++++++++++++++++++-
>  2 files changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> index 00ebda1..0160bdc 100644
> --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> @@ -24,6 +24,7 @@ Optional Properties:
>         - pclkN, clkN: Pairs of parent of input clock and input clock to the
>                 devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
>                 are supported currently.
> +- parents: phandle of parent power domains.
>
>  Node of a device using power domains must have a samsung,power-domain property
>  defined with a phandle to respective power domain.
> @@ -48,6 +49,7 @@ Example:
>         mfc_pd: power-domain@10044060 {
>                 compatible = "samsung,exynos4210-pd", "samsung,exynos7-pd-mfc";
>                 reg = <0x10044060 0x20>;
> +               parents = <&pd_top>;
>                 #power-domain-cells = <0>;
>         };

This seems like a good and generic approach to describe that a PM
domain could have a parent. I would suggest to rename it, such it
reflects its a PM domain binding though.

So, maybe we can add this as a common DT binding for the generic PM
domain instead of having it as Exynos specific?

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Amit Kachhap Nov. 25, 2014, 8:57 a.m. UTC | #2
On Tue, Nov 25, 2014 at 1:29 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 24 November 2014 at 14:04, Amit Daniel Kachhap
> <amit.daniel@samsung.com> wrote:
>> This patch adds supports for parent power domain. This will ensure
>> invoking of parent/child power domain on/off in a correct sequence.
>> In exynos7 SOC's, power domain controllers have parent and child
>> hierarchy.
>>
>> Cc: Kukjin Kim <kgene.kim@samsung.com>
>> Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
>> ---
>>  .../bindings/arm/exynos/power_domain.txt           |    2 +
>>  drivers/soc/samsung/pm_domains.c                   |   43 +++++++++++++++++++-
>>  2 files changed, 44 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
>> index 00ebda1..0160bdc 100644
>> --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
>> +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
>> @@ -24,6 +24,7 @@ Optional Properties:
>>         - pclkN, clkN: Pairs of parent of input clock and input clock to the
>>                 devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
>>                 are supported currently.
>> +- parents: phandle of parent power domains.
>>
>>  Node of a device using power domains must have a samsung,power-domain property
>>  defined with a phandle to respective power domain.
>> @@ -48,6 +49,7 @@ Example:
>>         mfc_pd: power-domain@10044060 {
>>                 compatible = "samsung,exynos4210-pd", "samsung,exynos7-pd-mfc";
>>                 reg = <0x10044060 0x20>;
>> +               parents = <&pd_top>;
>>                 #power-domain-cells = <0>;
>>         };
>
> This seems like a good and generic approach to describe that a PM
> domain could have a parent. I would suggest to rename it, such it
> reflects its a PM domain binding though.
I am not sure if this is generic. I guess PD's represented like below
are more generic.
PD1 {
        PD2 {
                PD3 {
                };
        };
};

>
> So, maybe we can add this as a common DT binding for the generic PM
> domain instead of having it as Exynos specific?
Yes sure.

Regards,
Amit D
>
> Kind regards
> Uffe
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Geert Uytterhoeven Nov. 25, 2014, 9:19 a.m. UTC | #3
On Tue, Nov 25, 2014 at 9:57 AM, amit daniel kachhap
<amit.daniel@samsung.com> wrote:
>>> diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
>>> index 00ebda1..0160bdc 100644
>>> --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
>>> +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
>>> @@ -24,6 +24,7 @@ Optional Properties:
>>>         - pclkN, clkN: Pairs of parent of input clock and input clock to the
>>>                 devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
>>>                 are supported currently.
>>> +- parents: phandle of parent power domains.

Why not using just "power-domains = <&pd_top>"?
This is consistent with how clocks refer to their parent clocks.

>>>  Node of a device using power domains must have a samsung,power-domain property
>>>  defined with a phandle to respective power domain.
>>> @@ -48,6 +49,7 @@ Example:
>>>         mfc_pd: power-domain@10044060 {
>>>                 compatible = "samsung,exynos4210-pd", "samsung,exynos7-pd-mfc";
>>>                 reg = <0x10044060 0x20>;
>>> +               parents = <&pd_top>;
>>>                 #power-domain-cells = <0>;
>>>         };
>>
>> This seems like a good and generic approach to describe that a PM
>> domain could have a parent. I would suggest to rename it, such it
>> reflects its a PM domain binding though.
> I am not sure if this is generic. I guess PD's represented like below
> are more generic.
> PD1 {
>         PD2 {
>                 PD3 {
>                 };
>         };
> };

Such a representation is not always possible.
If you have one power-controller for a hierarchy of PM domains, you can
use it.
If you have multiple power-controllers, the power controller nodes are at the
same level in DT, so you'll have to use "power-domains" properties to link
them together.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Marek Szyprowski Dec. 3, 2014, 8:36 a.m. UTC | #4
Hello,

On 2014-11-25 10:19, Geert Uytterhoeven wrote:
> On Tue, Nov 25, 2014 at 9:57 AM, amit daniel kachhap
> <amit.daniel@samsung.com>  wrote:
>>>> diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
>>>> index 00ebda1..0160bdc 100644
>>>> --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
>>>> @@ -24,6 +24,7 @@ Optional Properties:
>>>>          - pclkN, clkN: Pairs of parent of input clock and input clock to the
>>>>                  devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
>>>>                  are supported currently.
>>>> +- parents: phandle of parent power domains.
> Why not using just "power-domains = <&pd_top>"?
> This is consistent with how clocks refer to their parent clocks.

I agree. The only question is weather exynos dts should keep using 
samsung,power-domain
property, or switch to generic 'power-domains' approach. I assume that 
exynos-pm driver
should support both.

>>>>   Node of a device using power domains must have a samsung,power-domain property
>>>>   defined with a phandle to respective power domain.
>>>> @@ -48,6 +49,7 @@ Example:
>>>>          mfc_pd: power-domain@10044060 {
>>>>                  compatible = "samsung,exynos4210-pd", "samsung,exynos7-pd-mfc";
>>>>                  reg = <0x10044060 0x20>;
>>>> +               parents = <&pd_top>;
>>>>                  #power-domain-cells = <0>;
>>>>          };
>>> This seems like a good and generic approach to describe that a PM
>>> domain could have a parent. I would suggest to rename it, such it
>>> reflects its a PM domain binding though.
>> I am not sure if this is generic. I guess PD's represented like below
>> are more generic.
>> PD1 {
>>          PD2 {
>>                  PD3 {
>>                  };
>>          };
>> };
> Such a representation is not always possible.
> If you have one power-controller for a hierarchy of PM domains, you can
> use it.
> If you have multiple power-controllers, the power controller nodes are at the
> same level in DT, so you'll have to use "power-domains" properties to link
> them together.

I agree. I will send updated patch for this purpose for existing exynos4 
power domain driver.

Best regards
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index 00ebda1..0160bdc 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -24,6 +24,7 @@  Optional Properties:
 	- pclkN, clkN: Pairs of parent of input clock and input clock to the
 		devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
 		are supported currently.
+- parents: phandle of parent power domains.
 
 Node of a device using power domains must have a samsung,power-domain property
 defined with a phandle to respective power domain.
@@ -48,6 +49,7 @@  Example:
 	mfc_pd: power-domain@10044060 {
 		compatible = "samsung,exynos4210-pd", "samsung,exynos7-pd-mfc";
 		reg = <0x10044060 0x20>;
+		parents = <&pd_top>;
 		#power-domain-cells = <0>;
 	};
 
diff --git a/drivers/soc/samsung/pm_domains.c b/drivers/soc/samsung/pm_domains.c
index f4f2a6c..89e2fd5 100644
--- a/drivers/soc/samsung/pm_domains.c
+++ b/drivers/soc/samsung/pm_domains.c
@@ -25,10 +25,10 @@ 
 #include <linux/soc/samsung/exynos-pmu.h>
 
 #define MAX_CLK_PER_DOMAIN	4
+#define MAX_PARENT_POWER_DOMAIN	10
 
 static struct exynos_pmu_pd_ops *pd_ops;
 
-
 /*
  * Exynos specific wrapper around the generic power domain
  */
@@ -169,6 +169,47 @@  no_clk:
 		of_genpd_add_provider_simple(np, &pd->pd);
 	}
 
+	/* Assign the child power domains to their parents */
+	for_each_compatible_node(np, NULL, "samsung,exynos4210-pd") {
+		struct device_node *parent_np;
+		int i;
+		struct generic_pm_domain *child_domain, *parent_domain;
+		const char *name;
+
+		if (of_property_read_string_index(np, "compatible", 1,
+					&name)) {
+			/* Second entry not found, use the node name*/
+			name = np->name;
+		}
+
+		child_domain = pm_genpd_lookup_name(name);
+		if (!child_domain)
+			continue;
+		/* search parents in device tree */
+		for (i = 0; i < MAX_PARENT_POWER_DOMAIN; i++) {
+			parent_np = of_parse_phandle(np, "parents", i);
+			if (!parent_np)
+				break;
+
+			if (of_property_read_string_index(parent_np,
+						"compatible", 1, &name)) {
+				/* Second entry not found, use the node name*/
+				name = parent_np->name;
+			}
+
+			parent_domain = pm_genpd_lookup_name(name);
+			if (!parent_domain)
+				break;
+			if (pm_genpd_add_subdomain(parent_domain, child_domain))
+				pr_warn("%s failed to add subdomain: %s\n",
+						parent_domain->name,
+						child_domain->name);
+			else
+				pr_info("%s has as child subdomain: %s.\n",
+						parent_domain->name,
+						child_domain->name);
+		}
+	}
 	return 0;
 }