[RFD] PM: Device tree representation of power domains

[RFD] PM: Device tree representation of power domains

[Rafael J. Wysocki]

Hi all,

I actually don't have any ideas how to do that at the moment, but I wonder
if anyone has already thought about it?

For one, I don't think that representing a power domain as a platform device
would be a good approach and I'm not sure how to represent the relationships
between devices and the domains they belong to.

Thoughts?

Rafael

Re: [RFD] PM: Device tree representation of power domains

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

On Tue, Jul 03, 2012 at 11:02:17PM +0200, Rafael J. Wysocki wrote:

> I actually don't have any ideas how to do that at the moment, but I wonder
> if anyone has already thought about it?

> For one, I don't think that representing a power domain as a platform device
> would be a good approach and I'm not sure how to represent the relationships
> between devices and the domains they belong to.

I guess the OMAP hwmod stuff is the closest thing we've got at the
minute (I don't recall seeing any other implementations in mainline) but
the hwmods themselves don't appear in the DTS right now.  They have a
ti,hwmods property on each device naming the hwmod it's in, something
like that seems like a reasonable approach, possibly a reference to
another DT node rather than or as well as a string?  That seems fairly
easy.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [RFD] PM: Device tree representation of power domains

[Rafael J. Wysocki]

On Wednesday, July 04, 2012, Mark Brown wrote:
> On Tue, Jul 03, 2012 at 11:02:17PM +0200, Rafael J. Wysocki wrote:
> 
> > I actually don't have any ideas how to do that at the moment, but I wonder
> > if anyone has already thought about it?
> 
> > For one, I don't think that representing a power domain as a platform device
> > would be a good approach and I'm not sure how to represent the relationships
> > between devices and the domains they belong to.
> 
> I guess the OMAP hwmod stuff is the closest thing we've got at the
> minute (I don't recall seeing any other implementations in mainline) but
> the hwmods themselves don't appear in the DTS right now.  They have a
> ti,hwmods property on each device naming the hwmod it's in, something
> like that seems like a reasonable approach, possibly a reference to
> another DT node rather than or as well as a string?  That seems fairly
> easy.

Well, it looks like (and please tell me if I'm wrong) the hwmons are just
string attributes that are parsed by the platform-specific code through
a platform bus type notifier.

We could do that for power domains too, but then each platform wanting to
use them would need to implement such a notifier and add its own routine
for parsing those strings.  Would that be acceptable to everyone concerned?

Rafael

[RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)

[Rafael J. Wysocki]

On Thursday, July 05, 2012, Rafael J. Wysocki wrote:
> On Wednesday, July 04, 2012, Mark Brown wrote:
> > On Tue, Jul 03, 2012 at 11:02:17PM +0200, Rafael J. Wysocki wrote:
> > 
> > > I actually don't have any ideas how to do that at the moment, but I wonder
> > > if anyone has already thought about it?
> > 
> > > For one, I don't think that representing a power domain as a platform device
> > > would be a good approach and I'm not sure how to represent the relationships
> > > between devices and the domains they belong to.
> > 
> > I guess the OMAP hwmod stuff is the closest thing we've got at the
> > minute (I don't recall seeing any other implementations in mainline) but
> > the hwmods themselves don't appear in the DTS right now.  They have a
> > ti,hwmods property on each device naming the hwmod it's in, something
> > like that seems like a reasonable approach, possibly a reference to
> > another DT node rather than or as well as a string?  That seems fairly
> > easy.
> 
> Well, it looks like (and please tell me if I'm wrong) the hwmons are just
> string attributes that are parsed by the platform-specific code through
> a platform bus type notifier.
> 
> We could do that for power domains too, but then each platform wanting to
> use them would need to implement such a notifier and add its own routine
> for parsing those strings.  Would that be acceptable to everyone concerned?

I tried to follow the above suggestion and prepared the following patchset
that allows power domain information for Renesas platforms to be passed as
"renesas,pmdomain" string attribute of device nodes.  It adds functions
allowing the generic PM domains framework to use names for domain
identification in various situations and reworks the ARM/shmobile power domains
support code to used those functions instead of the "raw" ones that take
domain pointers as their arguments.  Finally, it defines a platform bus type
notifier that will add devices whose DT nodes contain the "renesas,pmdomain"
attribute to the power domains indicated by it (the value of that attribute
should be the name of the PM domain to add the device to after it's been
registered).  All of this should allow platform devices to be added to
appropriate power domains automatically based on the information read from
a DT.

The patches are on top of the current linux-next tree.

I've tested the patches that could be tested on the Mackerel board, except
for the last one (I'm still working on testing it).

Thanks,
Rafael

[RFC][PATCH 1/14] PM / Domains: Make it possible to use domain names when adding devices

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>

Add a new helper function __pm_genpd_name_add_device() allowing
a device to be added to a (registered) generic PM domain identified
by name.  Add a wrapper around it, pm_genpd_name_add_device(),
passing NULL as the last argument and reorganize pm_domains.h for the
new functions to be defined consistently with the existing ones.

These functions are useful for adding devices to PM domains whose
representations are stored in tables, when the caller doesn't know
the index of the domain to add the device to, but it knows the
domain's name.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 drivers/base/power/domain.c |   27 +++++++++++++++++++++++++++
 include/linux/pm_domain.h   |   42 +++++++++++++++++++++++++++++-------------
 2 files changed, 56 insertions(+), 13 deletions(-)

Index: linux/drivers/base/power/domain.c
===================================================================
--- linux.orig/drivers/base/power/domain.c
+++ linux/drivers/base/power/domain.c
@@ -1399,6 +1399,33 @@ int __pm_genpd_of_add_device(struct devi
 	return __pm_genpd_add_device(genpd, dev, td);
 }
 
+
+/**
+ * __pm_genpd_name_add_device - Find I/O PM domain and add a device to it.
+ * @domain_name: Name of the PM domain to add the device to.
+ * @dev: Device to be added.
+ * @td: Set of PM QoS timing parameters to attach to the device.
+ */
+int __pm_genpd_name_add_device(const char *domain_name, struct device *dev,
+			       struct gpd_timing_data *td)
+{
+	struct generic_pm_domain *genpd = NULL, *gpd;
+
+	if (IS_ERR_OR_NULL(domain_name) || IS_ERR_OR_NULL(dev))
+		return -EINVAL;
+
+	mutex_lock(&gpd_list_lock);
+	list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
+		if (!strcmp(gpd->name, domain_name)) {
+			genpd = gpd;
+			break;
+		}
+	}
+	mutex_unlock(&gpd_list_lock);
+
+	return __pm_genpd_add_device(genpd, dev, td);
+}
+
 /**
  * pm_genpd_remove_device - Remove a device from an I/O PM domain.
  * @genpd: PM domain to remove the device from.
Index: linux/include/linux/pm_domain.h
===================================================================
--- linux.orig/include/linux/pm_domain.h
+++ linux/include/linux/pm_domain.h
@@ -139,17 +139,9 @@ extern int __pm_genpd_of_add_device(stru
 				    struct device *dev,
 				    struct gpd_timing_data *td);
 
-static inline int pm_genpd_add_device(struct generic_pm_domain *genpd,
-				      struct device *dev)
-{
-	return __pm_genpd_add_device(genpd, dev, NULL);
-}
-
-static inline int pm_genpd_of_add_device(struct device_node *genpd_node,
-					 struct device *dev)
-{
-	return __pm_genpd_of_add_device(genpd_node, dev, NULL);
-}
+extern int __pm_genpd_name_add_device(const char *domain_name,
+				      struct device *dev,
+				      struct gpd_timing_data *td);
 
 extern int pm_genpd_remove_device(struct generic_pm_domain *genpd,
 				  struct device *dev);
@@ -189,8 +181,14 @@ static inline int __pm_genpd_add_device(
 {
 	return -ENOSYS;
 }
-static inline int pm_genpd_add_device(struct generic_pm_domain *genpd,
-				      struct device *dev)
+static inline int __pm_genpd_of_add_device(struct device_node *genpd_node,
+					   struct device *dev)
+{
+	return -ENOSYS;
+}
+static inline int __pm_genpd_name_add_device(char *domain_name,
+					     struct device *dev,
+					     struct gpd_timing_data *td)
 {
 	return -ENOSYS;
 }
@@ -245,6 +243,24 @@ static inline bool default_stop_ok(struc
 #define pm_domain_always_on_gov NULL
 #endif
 
+static inline int pm_genpd_add_device(struct generic_pm_domain *genpd,
+				      struct device *dev)
+{
+	return __pm_genpd_add_device(genpd, dev, NULL);
+}
+
+static inline int pm_genpd_of_add_device(struct device_node *genpd_node,
+					 struct device *dev)
+{
+	return __pm_genpd_of_add_device(genpd_node, dev, NULL);
+}
+
+static inline int pm_genpd_name_add_device(const char *domain_name,
+					   struct device *dev)
+{
+	return __pm_genpd_name_add_device(domain_name, dev, NULL);
+}
+
 static inline int pm_genpd_remove_callbacks(struct device *dev)
 {
 	return __pm_genpd_remove_callbacks(dev, true);

[RFC][PATCH 2/14] ARM: shmobile: Use names of power domains for adding devices to them

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>

Make the power management code under arch/arm/mach-shmobile/ use
names of power domains instead of pointers to domain objects for
adding devices to the domains.  This will allow us to put the
domain objects into tables and register them all in one shot
going forward.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 arch/arm/mach-shmobile/board-ap4evb.c            |   14 +++---
 arch/arm/mach-shmobile/board-armadillo800eva.c   |    6 +-
 arch/arm/mach-shmobile/board-mackerel.c          |   24 +++++------
 arch/arm/mach-shmobile/include/mach/pm-rmobile.h |    4 -
 arch/arm/mach-shmobile/pm-rmobile.c              |    4 -
 arch/arm/mach-shmobile/setup-r8a7740.c           |   20 ++++-----
 arch/arm/mach-shmobile/setup-sh7372.c            |   48 +++++++++++------------
 7 files changed, 60 insertions(+), 60 deletions(-)

Index: linux/arch/arm/mach-shmobile/pm-rmobile.c
===================================================================
--- linux.orig/arch/arm/mach-shmobile/pm-rmobile.c
+++ linux/arch/arm/mach-shmobile/pm-rmobile.c
@@ -149,12 +149,12 @@ void rmobile_init_pm_domain(struct rmobi
 	__rmobile_pd_power_up(rmobile_pd, false);
 }
 
-void rmobile_add_device_to_domain(struct rmobile_pm_domain *rmobile_pd,
+void rmobile_add_device_to_domain(const char *domain_name,
 				 struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 
-	pm_genpd_add_device(&rmobile_pd->genpd, dev);
+	pm_genpd_name_add_device(domain_name, dev);
 	if (pm_clk_no_clocks(dev))
 		pm_clk_add(dev, NULL);
 }
Index: linux/arch/arm/mach-shmobile/include/mach/pm-rmobile.h
===================================================================
--- linux.orig/arch/arm/mach-shmobile/include/mach/pm-rmobile.h
+++ linux/arch/arm/mach-shmobile/include/mach/pm-rmobile.h
@@ -31,13 +31,13 @@ struct rmobile_pm_domain *to_rmobile_pd(
 
 #ifdef CONFIG_PM
 extern void rmobile_init_pm_domain(struct rmobile_pm_domain *rmobile_pd);
-extern void rmobile_add_device_to_domain(struct rmobile_pm_domain *rmobile_pd,
+extern void rmobile_add_device_to_domain(const char *domain_name,
 					struct platform_device *pdev);
 extern void rmobile_pm_add_subdomain(struct rmobile_pm_domain *rmobile_pd,
 				    struct rmobile_pm_domain *rmobile_sd);
 #else
 #define rmobile_init_pm_domain(pd) do { } while (0)
-#define rmobile_add_device_to_domain(pd, pdev) do { } while (0)
+#define rmobile_add_device_to_domain(name, pdev) do { } while (0)
 #define rmobile_pm_add_subdomain(pd, sd) do { } while (0)
 #endif /* CONFIG_PM */
 
Index: linux/arch/arm/mach-shmobile/board-mackerel.c
===================================================================
--- linux.orig/arch/arm/mach-shmobile/board-mackerel.c
+++ linux/arch/arm/mach-shmobile/board-mackerel.c
@@ -1623,20 +1623,20 @@ static void __init mackerel_init(void)
 
 	platform_add_devices(mackerel_devices, ARRAY_SIZE(mackerel_devices));
 
-	rmobile_add_device_to_domain(&sh7372_pd_a4lc, &lcdc_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a4lc, &hdmi_lcdc_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a4lc, &meram_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a4mp, &fsi_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &usbhs0_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &usbhs1_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &nand_flash_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &sh_mmcif_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &sdhi0_device);
+	rmobile_add_device_to_domain("A4LC", &lcdc_device);
+	rmobile_add_device_to_domain("A4LC", &hdmi_lcdc_device);
+	rmobile_add_device_to_domain("A4LC", &meram_device);
+	rmobile_add_device_to_domain("A4MP", &fsi_device);
+	rmobile_add_device_to_domain("A3SP", &usbhs0_device);
+	rmobile_add_device_to_domain("A3SP", &usbhs1_device);
+	rmobile_add_device_to_domain("A3SP", &nand_flash_device);
+	rmobile_add_device_to_domain("A3SP", &sh_mmcif_device);
+	rmobile_add_device_to_domain("A3SP", &sdhi0_device);
 #if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &sdhi1_device);
+	rmobile_add_device_to_domain("A3SP", &sdhi1_device);
 #endif
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &sdhi2_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a4r, &ceu_device);
+	rmobile_add_device_to_domain("A3SP", &sdhi2_device);
+	rmobile_add_device_to_domain("A4R", &ceu_device);
 
 	hdmi_init_pm_clock();
 	sh7372_pm_init();
Index: linux/arch/arm/mach-shmobile/setup-sh7372.c
===================================================================
--- linux.orig/arch/arm/mach-shmobile/setup-sh7372.c
+++ linux/arch/arm/mach-shmobile/setup-sh7372.c
@@ -1023,30 +1023,30 @@ void __init sh7372_add_standard_devices(
 	platform_add_devices(sh7372_late_devices,
 			    ARRAY_SIZE(sh7372_late_devices));
 
-	rmobile_add_device_to_domain(&sh7372_pd_a3rv, &vpu_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a4mp, &spu0_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a4mp, &spu1_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &scif0_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &scif1_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &scif2_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &scif3_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &scif4_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &scif5_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &scif6_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &iic1_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &dma0_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &dma1_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &dma2_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &usb_dma0_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &usb_dma1_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a4r, &iic0_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a4r, &veu0_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a4r, &veu1_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a4r, &veu2_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a4r, &veu3_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a4r, &jpu_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a4r, &tmu00_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a4r, &tmu01_device);
+	rmobile_add_device_to_domain("A3RV", &vpu_device);
+	rmobile_add_device_to_domain("A4MP", &spu0_device);
+	rmobile_add_device_to_domain("A4MP", &spu1_device);
+	rmobile_add_device_to_domain("A3SP", &scif0_device);
+	rmobile_add_device_to_domain("A3SP", &scif1_device);
+	rmobile_add_device_to_domain("A3SP", &scif2_device);
+	rmobile_add_device_to_domain("A3SP", &scif3_device);
+	rmobile_add_device_to_domain("A3SP", &scif4_device);
+	rmobile_add_device_to_domain("A3SP", &scif5_device);
+	rmobile_add_device_to_domain("A3SP", &scif6_device);
+	rmobile_add_device_to_domain("A3SP", &iic1_device);
+	rmobile_add_device_to_domain("A3SP", &dma0_device);
+	rmobile_add_device_to_domain("A3SP", &dma1_device);
+	rmobile_add_device_to_domain("A3SP", &dma2_device);
+	rmobile_add_device_to_domain("A3SP", &usb_dma0_device);
+	rmobile_add_device_to_domain("A3SP", &usb_dma1_device);
+	rmobile_add_device_to_domain("A4R", &iic0_device);
+	rmobile_add_device_to_domain("A4R", &veu0_device);
+	rmobile_add_device_to_domain("A4R", &veu1_device);
+	rmobile_add_device_to_domain("A4R", &veu2_device);
+	rmobile_add_device_to_domain("A4R", &veu3_device);
+	rmobile_add_device_to_domain("A4R", &jpu_device);
+	rmobile_add_device_to_domain("A4R", &tmu00_device);
+	rmobile_add_device_to_domain("A4R", &tmu01_device);
 }
 
 static void __init sh7372_earlytimer_init(void)
Index: linux/arch/arm/mach-shmobile/board-ap4evb.c
===================================================================
--- linux.orig/arch/arm/mach-shmobile/board-ap4evb.c
+++ linux/arch/arm/mach-shmobile/board-ap4evb.c
@@ -1461,14 +1461,14 @@ static void __init ap4evb_init(void)
 
 	platform_add_devices(ap4evb_devices, ARRAY_SIZE(ap4evb_devices));
 
-	rmobile_add_device_to_domain(&sh7372_pd_a4lc, &lcdc1_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a4lc, &lcdc_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a4mp, &fsi_device);
+	rmobile_add_device_to_domain("A4LC", &lcdc1_device);
+	rmobile_add_device_to_domain("A4LC", &lcdc_device);
+	rmobile_add_device_to_domain("A4MP", &fsi_device);
 
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &sh_mmcif_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &sdhi0_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a3sp, &sdhi1_device);
-	rmobile_add_device_to_domain(&sh7372_pd_a4r, &ceu_device);
+	rmobile_add_device_to_domain("A3SP", &sh_mmcif_device);
+	rmobile_add_device_to_domain("A3SP", &sdhi0_device);
+	rmobile_add_device_to_domain("A3SP", &sdhi1_device);
+	rmobile_add_device_to_domain("A4R", &ceu_device);
 
 	hdmi_init_pm_clock();
 	fsi_init_pm_clock();
Index: linux/arch/arm/mach-shmobile/setup-r8a7740.c
===================================================================
--- linux.orig/arch/arm/mach-shmobile/setup-r8a7740.c
+++ linux/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -688,16 +688,16 @@ void __init r8a7740_add_standard_devices
 
 	/* add devices to PM domain  */
 
-	rmobile_add_device_to_domain(&r8a7740_pd_a3sp,	&scif0_device);
-	rmobile_add_device_to_domain(&r8a7740_pd_a3sp,	&scif1_device);
-	rmobile_add_device_to_domain(&r8a7740_pd_a3sp,	&scif2_device);
-	rmobile_add_device_to_domain(&r8a7740_pd_a3sp,	&scif3_device);
-	rmobile_add_device_to_domain(&r8a7740_pd_a3sp,	&scif4_device);
-	rmobile_add_device_to_domain(&r8a7740_pd_a3sp,	&scif5_device);
-	rmobile_add_device_to_domain(&r8a7740_pd_a3sp,	&scif6_device);
-	rmobile_add_device_to_domain(&r8a7740_pd_a3sp,	&scif7_device);
-	rmobile_add_device_to_domain(&r8a7740_pd_a3sp,	&scifb_device);
-	rmobile_add_device_to_domain(&r8a7740_pd_a3sp,	&i2c1_device);
+	rmobile_add_device_to_domain("A3SP",	&scif0_device);
+	rmobile_add_device_to_domain("A3SP",	&scif1_device);
+	rmobile_add_device_to_domain("A3SP",	&scif2_device);
+	rmobile_add_device_to_domain("A3SP",	&scif3_device);
+	rmobile_add_device_to_domain("A3SP",	&scif4_device);
+	rmobile_add_device_to_domain("A3SP",	&scif5_device);
+	rmobile_add_device_to_domain("A3SP",	&scif6_device);
+	rmobile_add_device_to_domain("A3SP",	&scif7_device);
+	rmobile_add_device_to_domain("A3SP",	&scifb_device);
+	rmobile_add_device_to_domain("A3SP",	&i2c1_device);
 }
 
 static void __init r8a7740_earlytimer_init(void)
Index: linux/arch/arm/mach-shmobile/board-armadillo800eva.c
===================================================================
--- linux.orig/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ linux/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -1181,10 +1181,10 @@ static void __init eva_init(void)
 
 	eva_clock_init();
 
-	rmobile_add_device_to_domain(&r8a7740_pd_a4lc, &lcdc0_device);
-	rmobile_add_device_to_domain(&r8a7740_pd_a4lc, &hdmi_lcdc_device);
+	rmobile_add_device_to_domain("A4LC", &lcdc0_device);
+	rmobile_add_device_to_domain("A4LC", &hdmi_lcdc_device);
 	if (usb)
-		rmobile_add_device_to_domain(&r8a7740_pd_a3sp, usb);
+		rmobile_add_device_to_domain("A3SP", usb);
 }
 
 static void __init eva_earlytimer_init(void)

[RFC][PATCH 3/14] ARM: shmobile: Drop r8a7779_add_device_to_domain()

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>

If the r8a7779's PM domains are given names, this SoC and its boards
will be able to use rmobile_add_device_to_domain() for adding devices
to those domains and r8a7779_add_device_to_domain(), which is not
used anywhere at the moment anyway, may be dopped.

Accordingly, give names to the r8a7779's PM domains and drop
r8a7779_add_device_to_domain().

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    3 ---
 arch/arm/mach-shmobile/pm-r8a7779.c           |   14 ++++----------
 2 files changed, 4 insertions(+), 13 deletions(-)

Index: linux/arch/arm/mach-shmobile/include/mach/r8a7779.h
===================================================================
--- linux.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ linux/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -353,11 +353,8 @@ extern struct r8a7779_pm_domain r8a7779_
 extern struct r8a7779_pm_domain r8a7779_impx3;
 
 extern void r8a7779_init_pm_domain(struct r8a7779_pm_domain *r8a7779_pd);
-extern void r8a7779_add_device_to_domain(struct r8a7779_pm_domain *r8a7779_pd,
-					struct platform_device *pdev);
 #else
 #define r8a7779_init_pm_domain(pd) do { } while (0)
-#define r8a7779_add_device_to_domain(pd, pdev) do { } while (0)
 #endif /* CONFIG_PM */
 
 #endif /* __ASM_R8A7779_H__ */
Index: linux/arch/arm/mach-shmobile/pm-r8a7779.c
===================================================================
--- linux.orig/arch/arm/mach-shmobile/pm-r8a7779.c
+++ linux/arch/arm/mach-shmobile/pm-r8a7779.c
@@ -199,17 +199,8 @@ void r8a7779_init_pm_domain(struct r8a77
 		pd_power_up(&r8a7779_pd->genpd);
 }
 
-void r8a7779_add_device_to_domain(struct r8a7779_pm_domain *r8a7779_pd,
-				 struct platform_device *pdev)
-{
-	struct device *dev = &pdev->dev;
-
-	pm_genpd_add_device(&r8a7779_pd->genpd, dev);
-	if (pm_clk_no_clocks(dev))
-		pm_clk_add(dev, NULL);
-}
-
 struct r8a7779_pm_domain r8a7779_sh4a = {
+	.genpd_name = "SH4A",
 	.ch = {
 		.chan_offs = 0x80, /* PWRSR1 .. PWRER1 */
 		.isr_bit = 16, /* SH4A */
@@ -217,6 +208,7 @@ struct r8a7779_pm_domain r8a7779_sh4a =
 };
 
 struct r8a7779_pm_domain r8a7779_sgx = {
+	.genpd_name = "SGX",
 	.ch = {
 		.chan_offs = 0xc0, /* PWRSR2 .. PWRER2 */
 		.isr_bit = 20, /* SGX */
@@ -224,6 +216,7 @@ struct r8a7779_pm_domain r8a7779_sgx = {
 };
 
 struct r8a7779_pm_domain r8a7779_vdp1 = {
+	.genpd_name = "VDP1",
 	.ch = {
 		.chan_offs = 0x100, /* PWRSR3 .. PWRER3 */
 		.isr_bit = 21, /* VDP */
@@ -231,6 +224,7 @@ struct r8a7779_pm_domain r8a7779_vdp1 =
 };
 
 struct r8a7779_pm_domain r8a7779_impx3 = {
+	.genpd_name = "IMPX3",
 	.ch = {
 		.chan_offs = 0x140, /* PWRSR4 .. PWRER4 */
 		.isr_bit = 24, /* IMP */

[RFC][PATCH 4/14] PM / Domains: Make it possible to use names when adding subdomains

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>

Add a new helper function, pm_genpd_add_subdomain_names(), allowing
the caller to add a subdomain to a generic PM domain using names for
domain identification (both domains have to be initialized before).

This function is useful for adding subdomains to PM domains whose
representations are stored in tables, when the caller doesn't know
the indices of the domain to add the subdomain to and of the
subdomain itself, but it knows the domains' names.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 drivers/base/power/domain.c |   32 +++++++++++++++++++++++++++++++-
 include/linux/pm_domain.h   |    7 +++++++
 2 files changed, 38 insertions(+), 1 deletion(-)

Index: linux/drivers/base/power/domain.c
===================================================================
--- linux.orig/drivers/base/power/domain.c
+++ linux/drivers/base/power/domain.c
@@ -1538,7 +1538,8 @@ int pm_genpd_add_subdomain(struct generi
 	struct gpd_link *link;
 	int ret = 0;
 
-	if (IS_ERR_OR_NULL(genpd) || IS_ERR_OR_NULL(subdomain))
+	if (IS_ERR_OR_NULL(genpd) || IS_ERR_OR_NULL(subdomain)
+	    || genpd == subdomain)
 		return -EINVAL;
 
  start:
@@ -1585,6 +1586,35 @@ int pm_genpd_add_subdomain(struct generi
 }
 
 /**
+ * pm_genpd_add_subdomain_names - Add a subdomain to an I/O PM domain.
+ * @master_name: Name of the master PM domain to add the subdomain to.
+ * @subdomain_name: Name of the subdomain to be added.
+ */
+int pm_genpd_add_subdomain_names(const char *master_name,
+				 const char *subdomain_name)
+{
+	struct generic_pm_domain *master = NULL, *subdomain = NULL, *gpd;
+
+	if (IS_ERR_OR_NULL(master_name) || IS_ERR_OR_NULL(subdomain_name))
+		return -EINVAL;
+
+	mutex_lock(&gpd_list_lock);
+	list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
+		if (!master && !strcmp(gpd->name, master_name))
+			master = gpd;
+
+		if (!subdomain && !strcmp(gpd->name, subdomain_name))
+			subdomain = gpd;
+
+		if (master && subdomain)
+			break;
+	}
+	mutex_unlock(&gpd_list_lock);
+
+	return pm_genpd_add_subdomain(master, subdomain);
+}
+
+/**
  * pm_genpd_remove_subdomain - Remove a subdomain from an I/O PM domain.
  * @genpd: Master PM domain to remove the subdomain from.
  * @subdomain: Subdomain to be removed.
Index: linux/include/linux/pm_domain.h
===================================================================
--- linux.orig/include/linux/pm_domain.h
+++ linux/include/linux/pm_domain.h
@@ -149,6 +149,8 @@ extern void pm_genpd_dev_always_on(struc
 extern void pm_genpd_dev_need_restore(struct device *dev, bool val);
 extern int pm_genpd_add_subdomain(struct generic_pm_domain *genpd,
 				  struct generic_pm_domain *new_subdomain);
+extern int pm_genpd_add_subdomain_names(const char *master_name,
+					const char *subdomain_name);
 extern int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
 				     struct generic_pm_domain *target);
 extern int pm_genpd_add_callbacks(struct device *dev,
@@ -204,6 +206,11 @@ static inline int pm_genpd_add_subdomain
 {
 	return -ENOSYS;
 }
+static inline int pm_genpd_add_subdomain_names(const char *master_name,
+					       const char *subdomain_name)
+{
+	return -ENOSYS;
+}
 static inline int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
 					    struct generic_pm_domain *target)
 {

[RFC][PATCH 5/14] ARM: shmobile: Use domain names when adding subdomains to power domains

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>

Make the power management code under arch/arm/mach-shmobile/
use pm_genpd_add_subdomain_names() for adding subdomains to power
domains, which makes it possible to drop
rmobile_pm_add_subdomain() and will allow us to carry out those
operations for domain objects stored in tables in a straightforward
way.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 arch/arm/mach-shmobile/include/mach/pm-rmobile.h |    3 ---
 arch/arm/mach-shmobile/pm-rmobile.c              |    6 ------
 arch/arm/mach-shmobile/setup-r8a7740.c           |    2 +-
 arch/arm/mach-shmobile/setup-sh7372.c            |    8 ++++----
 4 files changed, 5 insertions(+), 14 deletions(-)

Index: linux/arch/arm/mach-shmobile/include/mach/pm-rmobile.h
===================================================================
--- linux.orig/arch/arm/mach-shmobile/include/mach/pm-rmobile.h
+++ linux/arch/arm/mach-shmobile/include/mach/pm-rmobile.h
@@ -33,12 +33,9 @@ struct rmobile_pm_domain *to_rmobile_pd(
 extern void rmobile_init_pm_domain(struct rmobile_pm_domain *rmobile_pd);
 extern void rmobile_add_device_to_domain(const char *domain_name,
 					struct platform_device *pdev);
-extern void rmobile_pm_add_subdomain(struct rmobile_pm_domain *rmobile_pd,
-				    struct rmobile_pm_domain *rmobile_sd);
 #else
 #define rmobile_init_pm_domain(pd) do { } while (0)
 #define rmobile_add_device_to_domain(name, pdev) do { } while (0)
-#define rmobile_pm_add_subdomain(pd, sd) do { } while (0)
 #endif /* CONFIG_PM */
 
 #endif /* PM_RMOBILE_H */
Index: linux/arch/arm/mach-shmobile/pm-rmobile.c
===================================================================
--- linux.orig/arch/arm/mach-shmobile/pm-rmobile.c
+++ linux/arch/arm/mach-shmobile/pm-rmobile.c
@@ -158,10 +158,4 @@ void rmobile_add_device_to_domain(const
 	if (pm_clk_no_clocks(dev))
 		pm_clk_add(dev, NULL);
 }
-
-void rmobile_pm_add_subdomain(struct rmobile_pm_domain *rmobile_pd,
-			     struct rmobile_pm_domain *rmobile_sd)
-{
-	pm_genpd_add_subdomain(&rmobile_pd->genpd, &rmobile_sd->genpd);
-}
 #endif /* CONFIG_PM */
Index: linux/arch/arm/mach-shmobile/setup-r8a7740.c
===================================================================
--- linux.orig/arch/arm/mach-shmobile/setup-r8a7740.c
+++ linux/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -678,7 +678,7 @@ void __init r8a7740_add_standard_devices
 	rmobile_init_pm_domain(&r8a7740_pd_a3sp);
 	rmobile_init_pm_domain(&r8a7740_pd_a4lc);
 
-	rmobile_pm_add_subdomain(&r8a7740_pd_a4s, &r8a7740_pd_a3sp);
+	pm_genpd_add_subdomain_names("A4S", "A3SP");
 
 	/* add devices */
 	platform_add_devices(r8a7740_early_devices,
Index: linux/arch/arm/mach-shmobile/setup-sh7372.c
===================================================================
--- linux.orig/arch/arm/mach-shmobile/setup-sh7372.c
+++ linux/arch/arm/mach-shmobile/setup-sh7372.c
@@ -1011,11 +1011,11 @@ void __init sh7372_add_standard_devices(
 	rmobile_init_pm_domain(&sh7372_pd_a3sp);
 	rmobile_init_pm_domain(&sh7372_pd_a3sg);
 
-	rmobile_pm_add_subdomain(&sh7372_pd_a4lc, &sh7372_pd_a3rv);
-	rmobile_pm_add_subdomain(&sh7372_pd_a4r, &sh7372_pd_a4lc);
+	pm_genpd_add_subdomain_names("A4LC", "A3RV");
+	pm_genpd_add_subdomain_names("A4R", "A4LC");
 
-	rmobile_pm_add_subdomain(&sh7372_pd_a4s, &sh7372_pd_a3sg);
-	rmobile_pm_add_subdomain(&sh7372_pd_a4s, &sh7372_pd_a3sp);
+	pm_genpd_add_subdomain_names("A4S", "A3SG");
+	pm_genpd_add_subdomain_names("A4S", "A3SP");
 
 	platform_add_devices(sh7372_early_devices,
 			    ARRAY_SIZE(sh7372_early_devices));

[RFC][PATCH 6/14] RM: shmobile: Add routine for automatic PM domains initialization

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>

Add a new routine, rmobile_init_domains(), allowing the caller
to initialize all generic PM objects stored in a table in one
operation.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 arch/arm/mach-shmobile/include/mach/pm-rmobile.h |    2 ++
 arch/arm/mach-shmobile/pm-rmobile.c              |    8 ++++++++
 2 files changed, 10 insertions(+)

Index: linux/arch/arm/mach-shmobile/pm-rmobile.c
===================================================================
--- linux.orig/arch/arm/mach-shmobile/pm-rmobile.c
+++ linux/arch/arm/mach-shmobile/pm-rmobile.c
@@ -149,6 +149,14 @@ void rmobile_init_pm_domain(struct rmobi
 	__rmobile_pd_power_up(rmobile_pd, false);
 }
 
+void rmobile_init_domains(struct rmobile_pm_domain domains[], int num)
+{
+	int j;
+
+	for (j = 0; j < num; j++)
+		rmobile_init_pm_domain(&domains[j]);
+}
+
 void rmobile_add_device_to_domain(const char *domain_name,
 				 struct platform_device *pdev)
 {
Index: linux/arch/arm/mach-shmobile/include/mach/pm-rmobile.h
===================================================================
--- linux.orig/arch/arm/mach-shmobile/include/mach/pm-rmobile.h
+++ linux/arch/arm/mach-shmobile/include/mach/pm-rmobile.h
@@ -31,10 +31,12 @@ struct rmobile_pm_domain *to_rmobile_pd(
 
 #ifdef CONFIG_PM
 extern void rmobile_init_pm_domain(struct rmobile_pm_domain *rmobile_pd);
+extern void rmobile_init_domains(struct rmobile_pm_domain domains[], int num);
 extern void rmobile_add_device_to_domain(const char *domain_name,
 					struct platform_device *pdev);
 #else
 #define rmobile_init_pm_domain(pd) do { } while (0)
+#define rmobile_init_domains(domains, num) do { } while (0)
 #define rmobile_add_device_to_domain(name, pdev) do { } while (0)
 #endif /* CONFIG_PM */
 

[RFC][PATCH 7/14] ARM: shmobile: Remove dead sh7372 power management code

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>

Since the sh7372_pd_a4s.genpd.status == GPD_STATE_POWER_OFF condition
is never satisfied, remove the code depending on it for now.
That (or equivalent) code will be added again when the cpuidle state
involving the A4S domain is added to the sh7372's cpuidle driver.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 arch/arm/mach-shmobile/pm-sh7372.c |   94 -------------------------------------
 1 file changed, 94 deletions(-)

Index: linux/arch/arm/mach-shmobile/pm-sh7372.c
===================================================================
--- linux.orig/arch/arm/mach-shmobile/pm-sh7372.c
+++ linux/arch/arm/mach-shmobile/pm-sh7372.c
@@ -174,75 +174,6 @@ static void sh7372_enter_sysc(int pllc0_
 	__raw_writel(0, SBAR);
 }
 
-static int sh7372_sysc_valid(unsigned long *mskp, unsigned long *msk2p)
-{
-	unsigned long mstpsr0, mstpsr1, mstpsr2, mstpsr3, mstpsr4;
-	unsigned long msk, msk2;
-
-	/* check active clocks to determine potential wakeup sources */
-
-	mstpsr0 = __raw_readl(MSTPSR0);
-	if ((mstpsr0 & 0x00000003) != 0x00000003) {
-		pr_debug("sh7372 mstpsr0 0x%08lx\n", mstpsr0);
-		return 0;
-	}
-
-	mstpsr1 = __raw_readl(MSTPSR1);
-	if ((mstpsr1 & 0xff079b7f) != 0xff079b7f) {
-		pr_debug("sh7372 mstpsr1 0x%08lx\n", mstpsr1);
-		return 0;
-	}
-
-	mstpsr2 = __raw_readl(MSTPSR2);
-	if ((mstpsr2 & 0x000741ff) != 0x000741ff) {
-		pr_debug("sh7372 mstpsr2 0x%08lx\n", mstpsr2);
-		return 0;
-	}
-
-	mstpsr3 = __raw_readl(MSTPSR3);
-	if ((mstpsr3 & 0x1a60f010) != 0x1a60f010) {
-		pr_debug("sh7372 mstpsr3 0x%08lx\n", mstpsr3);
-		return 0;
-	}
-
-	mstpsr4 = __raw_readl(MSTPSR4);
-	if ((mstpsr4 & 0x00008cf0) != 0x00008cf0) {
-		pr_debug("sh7372 mstpsr4 0x%08lx\n", mstpsr4);
-		return 0;
-	}
-
-	msk = 0;
-	msk2 = 0;
-
-	/* make bitmaps of limited number of wakeup sources */
-
-	if ((mstpsr2 & (1 << 23)) == 0) /* SPU2 */
-		msk |= 1 << 31;
-
-	if ((mstpsr2 & (1 << 12)) == 0) /* MFI_MFIM */
-		msk |= 1 << 21;
-
-	if ((mstpsr4 & (1 << 3)) == 0) /* KEYSC */
-		msk |= 1 << 2;
-
-	if ((mstpsr1 & (1 << 24)) == 0) /* CMT0 */
-		msk |= 1 << 1;
-
-	if ((mstpsr3 & (1 << 29)) == 0) /* CMT1 */
-		msk |= 1 << 1;
-
-	if ((mstpsr4 & (1 << 0)) == 0) /* CMT2 */
-		msk |= 1 << 1;
-
-	if ((mstpsr2 & (1 << 13)) == 0) /* MFI_MFIS */
-		msk2 |= 1 << 17;
-
-	*mskp = msk;
-	*msk2p = msk2;
-
-	return 1;
-}
-
 static void sh7372_icr_to_irqcr(unsigned long icr, u16 *irqcr1p, u16 *irqcr2p)
 {
 	u16 tmp, irqcr1, irqcr2;
@@ -375,33 +306,8 @@ static void sh7372_cpuidle_init(void) {}
 #endif
 
 #ifdef CONFIG_SUSPEND
-static void sh7372_enter_a4s_common(int pllc0_on)
-{
-	sh7372_intca_suspend();
-	memcpy((void *)SMFRAM, sh7372_resume_core_standby_sysc, 0x100);
-	sh7372_set_reset_vector(SMFRAM);
-	sh7372_enter_sysc(pllc0_on, 1 << 10);
-	sh7372_intca_resume();
-}
-
 static int sh7372_enter_suspend(suspend_state_t suspend_state)
 {
-	unsigned long msk, msk2;
-
-	/* check active clocks to determine potential wakeup sources */
-	if (sh7372_sysc_valid(&msk, &msk2)) {
-		if (!console_suspend_enabled &&
-		    sh7372_pd_a4s.genpd.status == GPD_STATE_POWER_OFF) {
-			/* convert INTC mask/sense to SYSC mask/sense */
-			sh7372_setup_sysc(msk, msk2);
-
-			/* enter A4S sleep with PLLC0 off */
-			pr_debug("entering A4S\n");
-			sh7372_enter_a4s_common(0);
-			return 0;
-		}
-	}
-
 	/* default to enter A3SM sleep with PLLC0 off */
 	pr_debug("entering A3SM\n");
 	sh7372_enter_a3sm_common(0);

[RFC][PATCH 8/14] PM / Domains: Add power-on function using names to identify domains

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>

It sometimes is necessary to turn on a given PM domain when only
the name of it is known and the domain pointer is not readily
available.  For this reason, add a new helper function,
pm_genpd_name_poweron(), allowing the caller to turn on a PM domain
using its name for identification.  To avoid code duplication,
move the domain lookup code to a separate function.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 drivers/base/power/domain.c |   46 +++++++++++++++++++++++++++++---------------
 include/linux/pm_domain.h   |    5 ++++
 2 files changed, 36 insertions(+), 15 deletions(-)

Index: linux/drivers/base/power/domain.c
===================================================================
--- linux.orig/drivers/base/power/domain.c
+++ linux/drivers/base/power/domain.c
@@ -53,6 +53,24 @@
 static LIST_HEAD(gpd_list);
 static DEFINE_MUTEX(gpd_list_lock);
 
+static struct generic_pm_domain *pm_genpd_lookup_name(const char *domain_name)
+{
+	struct generic_pm_domain *genpd = NULL, *gpd;
+
+	if (IS_ERR_OR_NULL(domain_name))
+		return NULL;
+
+	mutex_lock(&gpd_list_lock);
+	list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
+		if (!strcmp(gpd->name, domain_name)) {
+			genpd = gpd;
+			break;
+		}
+	}
+	mutex_unlock(&gpd_list_lock);
+	return genpd;
+}
+
 #ifdef CONFIG_PM
 
 struct generic_pm_domain *dev_to_genpd(struct device *dev)
@@ -258,6 +276,18 @@ int pm_genpd_poweron(struct generic_pm_d
 	return ret;
 }
 
+/**
+ * pm_genpd_name_poweron - Restore power to a given PM domain and its masters.
+ * @domain_name: Name of the PM domain to power up.
+ */
+int pm_genpd_name_poweron(const char *domain_name)
+{
+	struct generic_pm_domain *genpd;
+
+	genpd = pm_genpd_lookup_name(domain_name);
+	return genpd ? pm_genpd_poweron(genpd) : -EINVAL;
+}
+
 #endif /* CONFIG_PM */
 
 #ifdef CONFIG_PM_RUNTIME
@@ -1409,21 +1439,7 @@ int __pm_genpd_of_add_device(struct devi
 int __pm_genpd_name_add_device(const char *domain_name, struct device *dev,
 			       struct gpd_timing_data *td)
 {
-	struct generic_pm_domain *genpd = NULL, *gpd;
-
-	if (IS_ERR_OR_NULL(domain_name) || IS_ERR_OR_NULL(dev))
-		return -EINVAL;
-
-	mutex_lock(&gpd_list_lock);
-	list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
-		if (!strcmp(gpd->name, domain_name)) {
-			genpd = gpd;
-			break;
-		}
-	}
-	mutex_unlock(&gpd_list_lock);
-
-	return __pm_genpd_add_device(genpd, dev, td);
+	return __pm_genpd_add_device(pm_genpd_lookup_name(domain_name), dev, td);
 }
 
 /**
Index: linux/include/linux/pm_domain.h
===================================================================
--- linux.orig/include/linux/pm_domain.h
+++ linux/include/linux/pm_domain.h
@@ -163,6 +163,7 @@ extern void pm_genpd_init(struct generic
 			  struct dev_power_governor *gov, bool is_off);
 
 extern int pm_genpd_poweron(struct generic_pm_domain *genpd);
+extern int pm_genpd_name_poweron(const char *domain_name);
 
 extern bool default_stop_ok(struct device *dev);
 
@@ -242,6 +243,10 @@ static inline int pm_genpd_poweron(struc
 {
 	return -ENOSYS;
 }
+static inline int pm_genpd_name_poweron(const char *domain_name)
+{
+	return -ENOSYS;
+}
 static inline bool default_stop_ok(struct device *dev)
 {
 	return false;

[RFC][PATCH 9/14] ARM: shmobile: Move sh7372's PM domain objects to a table

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>

Instead of giving a name to every sh7372's PM domain object, put them
all into a table and use rmobile_init_domains(), introduced by a
previous patch, for initializing them all altogether.  Also, use
pm_genpd_add_subdomain_names() for adding subdomains to the PM
domains and pm_genpd_poweron_name() for turning on the A4S domain
when preparing for system suspend.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 arch/arm/mach-shmobile/include/mach/sh7372.h |   18 +---
 arch/arm/mach-shmobile/pm-sh7372.c           |  109 +++++++++++++--------------
 arch/arm/mach-shmobile/setup-sh7372.c        |   16 ---
 3 files changed, 63 insertions(+), 80 deletions(-)

Index: linux/arch/arm/mach-shmobile/pm-sh7372.c
===================================================================
--- linux.orig/arch/arm/mach-shmobile/pm-sh7372.c
+++ linux/arch/arm/mach-shmobile/pm-sh7372.c
@@ -71,21 +71,6 @@
 
 #ifdef CONFIG_PM
 
-struct rmobile_pm_domain sh7372_pd_a4lc = {
-	.genpd.name = "A4LC",
-	.bit_shift = 1,
-};
-
-struct rmobile_pm_domain sh7372_pd_a4mp = {
-	.genpd.name = "A4MP",
-	.bit_shift = 2,
-};
-
-struct rmobile_pm_domain sh7372_pd_d4 = {
-	.genpd.name = "D4",
-	.bit_shift = 3,
-};
-
 static int sh7372_a4r_pd_suspend(void)
 {
 	sh7372_intcs_suspend();
@@ -93,40 +78,15 @@ static int sh7372_a4r_pd_suspend(void)
 	return 0;
 }
 
-struct rmobile_pm_domain sh7372_pd_a4r = {
-	.genpd.name = "A4R",
-	.bit_shift = 5,
-	.suspend = sh7372_a4r_pd_suspend,
-	.resume = sh7372_intcs_resume,
-};
-
-struct rmobile_pm_domain sh7372_pd_a3rv = {
-	.genpd.name = "A3RV",
-	.bit_shift = 6,
-};
-
-struct rmobile_pm_domain sh7372_pd_a3ri = {
-	.genpd.name = "A3RI",
-	.bit_shift = 8,
-};
-
-static int sh7372_pd_a4s_suspend(void)
+static int sh7372_a4s_pd_suspend(void)
 {
 	/*
 	 * The A4S domain contains the CPU core and therefore it should
-	 * only be turned off if the CPU is in use.
+	 * only be turned off if the CPU is not in use.
 	 */
 	return -EBUSY;
 }
 
-struct rmobile_pm_domain sh7372_pd_a4s = {
-	.genpd.name = "A4S",
-	.bit_shift = 10,
-	.gov = &pm_domain_always_on_gov,
-	.no_debug = true,
-	.suspend = sh7372_pd_a4s_suspend,
-};
-
 static int sh7372_a3sp_pd_suspend(void)
 {
 	/*
@@ -136,18 +96,61 @@ static int sh7372_a3sp_pd_suspend(void)
 	return console_suspend_enabled ? 0 : -EBUSY;
 }
 
-struct rmobile_pm_domain sh7372_pd_a3sp = {
-	.genpd.name = "A3SP",
-	.bit_shift = 11,
-	.gov = &pm_domain_always_on_gov,
-	.no_debug = true,
-	.suspend = sh7372_a3sp_pd_suspend,
+static struct rmobile_pm_domain sh7372_pm_domains[] = {
+	{
+		.genpd.name = "A4LC",
+		.bit_shift = 1,
+	},
+	{
+		.genpd.name = "A4MP",
+		.bit_shift = 2,
+	},
+	{
+		.genpd.name = "D4",
+		.bit_shift = 3,
+	},
+	{
+		.genpd.name = "A4R",
+		.bit_shift = 5,
+		.suspend = sh7372_a4r_pd_suspend,
+		.resume = sh7372_intcs_resume,
+	},
+	{
+		.genpd.name = "A3RV",
+		.bit_shift = 6,
+	},
+	{
+		.genpd.name = "A3RI",
+		.bit_shift = 8,
+	},
+	{
+		.genpd.name = "A4S",
+		.bit_shift = 10,
+		.gov = &pm_domain_always_on_gov,
+		.no_debug = true,
+		.suspend = sh7372_a4s_pd_suspend,
+	},
+	{
+		.genpd.name = "A3SP",
+		.bit_shift = 11,
+		.gov = &pm_domain_always_on_gov,
+		.no_debug = true,
+		.suspend = sh7372_a3sp_pd_suspend,
+	},
+	{
+		.genpd.name = "A3SG",
+		.bit_shift = 13,
+	},
 };
 
-struct rmobile_pm_domain sh7372_pd_a3sg = {
-	.genpd.name = "A3SG",
-	.bit_shift = 13,
-};
+void __init sh7372_init_pm_domains(void)
+{
+	rmobile_init_domains(sh7372_pm_domains, ARRAY_SIZE(sh7372_pm_domains));
+	pm_genpd_add_subdomain_names("A4LC", "A3RV");
+	pm_genpd_add_subdomain_names("A4R", "A4LC");
+	pm_genpd_add_subdomain_names("A4S", "A3SG");
+	pm_genpd_add_subdomain_names("A4S", "A3SP");
+}
 
 #endif /* CONFIG_PM */
 
@@ -331,7 +334,7 @@ static int sh7372_pm_notifier_fn(struct
 		 * executed during system suspend and resume, respectively, so
 		 * that those functions don't crash while accessing the INTCS.
 		 */
-		pm_genpd_poweron(&sh7372_pd_a4r.genpd);
+		pm_genpd_name_poweron("A4R");
 		break;
 	case PM_POST_SUSPEND:
 		pm_genpd_poweroff_unused();
Index: linux/arch/arm/mach-shmobile/setup-sh7372.c
===================================================================
--- linux.orig/arch/arm/mach-shmobile/setup-sh7372.c
+++ linux/arch/arm/mach-shmobile/setup-sh7372.c
@@ -1001,21 +1001,7 @@ static struct platform_device *sh7372_la
 
 void __init sh7372_add_standard_devices(void)
 {
-	rmobile_init_pm_domain(&sh7372_pd_a4lc);
-	rmobile_init_pm_domain(&sh7372_pd_a4mp);
-	rmobile_init_pm_domain(&sh7372_pd_d4);
-	rmobile_init_pm_domain(&sh7372_pd_a4r);
-	rmobile_init_pm_domain(&sh7372_pd_a3rv);
-	rmobile_init_pm_domain(&sh7372_pd_a3ri);
-	rmobile_init_pm_domain(&sh7372_pd_a4s);
-	rmobile_init_pm_domain(&sh7372_pd_a3sp);
-	rmobile_init_pm_domain(&sh7372_pd_a3sg);
-
-	pm_genpd_add_subdomain_names("A4LC", "A3RV");
-	pm_genpd_add_subdomain_names("A4R", "A4LC");
-
-	pm_genpd_add_subdomain_names("A4S", "A3SG");
-	pm_genpd_add_subdomain_names("A4S", "A3SP");
+	sh7372_init_pm_domains();
 
 	platform_add_devices(sh7372_early_devices,
 			    ARRAY_SIZE(sh7372_early_devices));
Index: linux/arch/arm/mach-shmobile/include/mach/sh7372.h
===================================================================
--- linux.orig/arch/arm/mach-shmobile/include/mach/sh7372.h
+++ linux/arch/arm/mach-shmobile/include/mach/sh7372.h
@@ -478,21 +478,15 @@ extern struct clk sh7372_fsibck_clk;
 extern struct clk sh7372_fsidiva_clk;
 extern struct clk sh7372_fsidivb_clk;
 
-#ifdef CONFIG_PM
-extern struct rmobile_pm_domain sh7372_pd_a4lc;
-extern struct rmobile_pm_domain sh7372_pd_a4mp;
-extern struct rmobile_pm_domain sh7372_pd_d4;
-extern struct rmobile_pm_domain sh7372_pd_a4r;
-extern struct rmobile_pm_domain sh7372_pd_a3rv;
-extern struct rmobile_pm_domain sh7372_pd_a3ri;
-extern struct rmobile_pm_domain sh7372_pd_a4s;
-extern struct rmobile_pm_domain sh7372_pd_a3sp;
-extern struct rmobile_pm_domain sh7372_pd_a3sg;
-#endif /* CONFIG_PM */
-
 extern void sh7372_intcs_suspend(void);
 extern void sh7372_intcs_resume(void);
 extern void sh7372_intca_suspend(void);
 extern void sh7372_intca_resume(void);
 
+#ifdef CONFIG_PM
+extern void __init sh7372_init_pm_domains(void);
+#else
+static inline void sh7372_init_pm_domains(void) {}
+#endif
+
 #endif /* __ASM_SH7372_H__ */

[RFC][PATCH 10/14] ARM: shmobile: Move r8a7740's PM domain objects to a table

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>

Instead of giving a name to every r8a7740's PM domain object, put
them all into a table and use rmobile_init_domains(), introduced by a
previous patch, for initializing them all altogether.  Also, use
pm_genpd_add_subdomain_names() for adding A3SP as a subdomain of A4S.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 arch/arm/mach-shmobile/include/mach/r8a7740.h |    6 +--
 arch/arm/mach-shmobile/pm-r8a7740.c           |   42 ++++++++++++++------------
 arch/arm/mach-shmobile/setup-r8a7740.c        |    7 ----
 3 files changed, 28 insertions(+), 27 deletions(-)

Index: linux/arch/arm/mach-shmobile/pm-r8a7740.c
===================================================================
--- linux.orig/arch/arm/mach-shmobile/pm-r8a7740.c
+++ linux/arch/arm/mach-shmobile/pm-r8a7740.c
@@ -21,14 +21,6 @@ static int r8a7740_pd_a4s_suspend(void)
 	return -EBUSY;
 }
 
-struct rmobile_pm_domain r8a7740_pd_a4s = {
-	.genpd.name	= "A4S",
-	.bit_shift	= 10,
-	.gov		= &pm_domain_always_on_gov,
-	.no_debug	= true,
-	.suspend	= r8a7740_pd_a4s_suspend,
-};
-
 static int r8a7740_pd_a3sp_suspend(void)
 {
 	/*
@@ -38,17 +30,31 @@ static int r8a7740_pd_a3sp_suspend(void)
 	return console_suspend_enabled ? 0 : -EBUSY;
 }
 
-struct rmobile_pm_domain r8a7740_pd_a3sp = {
-	.genpd.name	= "A3SP",
-	.bit_shift	= 11,
-	.gov		= &pm_domain_always_on_gov,
-	.no_debug	= true,
-	.suspend	= r8a7740_pd_a3sp_suspend,
+static struct rmobile_pm_domain r8a7740_pm_domains[] = {
+	{
+		.genpd.name	= "A4S",
+		.bit_shift	= 10,
+		.gov		= &pm_domain_always_on_gov,
+		.no_debug	= true,
+		.suspend	= r8a7740_pd_a4s_suspend,
+	},
+	{
+		.genpd.name	= "A3SP",
+		.bit_shift	= 11,
+		.gov		= &pm_domain_always_on_gov,
+		.no_debug	= true,
+		.suspend	= r8a7740_pd_a3sp_suspend,
+	},
+	{
+		.genpd.name	= "A4LC",
+		.bit_shift	= 1,
+	},
 };
 
-struct rmobile_pm_domain r8a7740_pd_a4lc = {
-	.genpd.name	= "A4LC",
-	.bit_shift	= 1,
-};
+void __init r8a7740_init_pm_domains(void)
+{
+	rmobile_init_domains(r8a7740_pm_domains, ARRAY_SIZE(r8a7740_pm_domains));
+	pm_genpd_add_subdomain_names("A4S", "A3SP");
+}
 
 #endif /* CONFIG_PM */
Index: linux/arch/arm/mach-shmobile/setup-r8a7740.c
===================================================================
--- linux.orig/arch/arm/mach-shmobile/setup-r8a7740.c
+++ linux/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -673,12 +673,7 @@ void __init r8a7740_add_standard_devices
 	r8a7740_i2c_workaround(&i2c0_device);
 	r8a7740_i2c_workaround(&i2c1_device);
 
-	/* PM domain */
-	rmobile_init_pm_domain(&r8a7740_pd_a4s);
-	rmobile_init_pm_domain(&r8a7740_pd_a3sp);
-	rmobile_init_pm_domain(&r8a7740_pd_a4lc);
-
-	pm_genpd_add_subdomain_names("A4S", "A3SP");
+	r8a7740_init_pm_domains();
 
 	/* add devices */
 	platform_add_devices(r8a7740_early_devices,
Index: linux/arch/arm/mach-shmobile/include/mach/r8a7740.h
===================================================================
--- linux.orig/arch/arm/mach-shmobile/include/mach/r8a7740.h
+++ linux/arch/arm/mach-shmobile/include/mach/r8a7740.h
@@ -607,9 +607,9 @@ enum {
 };
 
 #ifdef CONFIG_PM
-extern struct rmobile_pm_domain r8a7740_pd_a4s;
-extern struct rmobile_pm_domain r8a7740_pd_a3sp;
-extern struct rmobile_pm_domain r8a7740_pd_a4lc;
+extern void __init r8a7740_init_pm_domains(void);
+#else
+static inline void r8a7740_init_pm_domains(void) {}
 #endif /* CONFIG_PM */
 
 #endif /* __ASM_R8A7740_H__ */

[RFC][PATCH 11/14] ARM: shmobile: Move r8a7779's PM domain objects to a table

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>

Instead of giving a name to every r8a7779's PM domain object, put
them all into a table and initialize them all together in a loop.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 arch/arm/mach-shmobile/include/mach/r8a7779.h |    9 ---
 arch/arm/mach-shmobile/pm-r8a7779.c           |   65 ++++++++++++++------------
 arch/arm/mach-shmobile/setup-r8a7779.c        |    5 --
 3 files changed, 39 insertions(+), 40 deletions(-)

Index: linux/arch/arm/mach-shmobile/include/mach/r8a7779.h
===================================================================
--- linux.orig/arch/arm/mach-shmobile/include/mach/r8a7779.h
+++ linux/arch/arm/mach-shmobile/include/mach/r8a7779.h
@@ -347,14 +347,9 @@ extern int r8a7779_sysc_power_down(struc
 extern int r8a7779_sysc_power_up(struct r8a7779_pm_ch *r8a7779_ch);
 
 #ifdef CONFIG_PM
-extern struct r8a7779_pm_domain r8a7779_sh4a;
-extern struct r8a7779_pm_domain r8a7779_sgx;
-extern struct r8a7779_pm_domain r8a7779_vdp1;
-extern struct r8a7779_pm_domain r8a7779_impx3;
-
-extern void r8a7779_init_pm_domain(struct r8a7779_pm_domain *r8a7779_pd);
+extern void __init r8a7779_init_pm_domains(void);
 #else
-#define r8a7779_init_pm_domain(pd) do { } while (0)
+static inline void r8a7779_init_pm_domains(void) {}
 #endif /* CONFIG_PM */
 
 #endif /* __ASM_R8A7779_H__ */
Index: linux/arch/arm/mach-shmobile/pm-r8a7779.c
===================================================================
--- linux.orig/arch/arm/mach-shmobile/pm-r8a7779.c
+++ linux/arch/arm/mach-shmobile/pm-r8a7779.c
@@ -183,7 +183,7 @@ static bool pd_active_wakeup(struct devi
 	return true;
 }
 
-void r8a7779_init_pm_domain(struct r8a7779_pm_domain *r8a7779_pd)
+static void r8a7779_init_pm_domain(struct r8a7779_pm_domain *r8a7779_pd)
 {
 	struct generic_pm_domain *genpd = &r8a7779_pd->genpd;
 
@@ -199,37 +199,44 @@ void r8a7779_init_pm_domain(struct r8a77
 		pd_power_up(&r8a7779_pd->genpd);
 }
 
-struct r8a7779_pm_domain r8a7779_sh4a = {
-	.genpd_name = "SH4A",
-	.ch = {
-		.chan_offs = 0x80, /* PWRSR1 .. PWRER1 */
-		.isr_bit = 16, /* SH4A */
-	}
+static struct r8a7779_pm_domain r8a7779_pm_domains[] = {
+	{
+		.genpd_name = "SH4A",
+		.ch = {
+			.chan_offs = 0x80, /* PWRSR1 .. PWRER1 */
+			.isr_bit = 16, /* SH4A */
+		},
+	},
+	{
+		.genpd_name = "SGX",
+		.ch = {
+			.chan_offs = 0xc0, /* PWRSR2 .. PWRER2 */
+			.isr_bit = 20, /* SGX */
+		},
+	},
+	{
+		.genpd_name = "VDP1",
+		.ch = {
+			.chan_offs = 0x100, /* PWRSR3 .. PWRER3 */
+			.isr_bit = 21, /* VDP */
+		},
+	},
+	{
+		.genpd_name = "IMPX3",
+		.ch = {
+			.chan_offs = 0x140, /* PWRSR4 .. PWRER4 */
+			.isr_bit = 24, /* IMP */
+		},
+	},
 };
 
-struct r8a7779_pm_domain r8a7779_sgx = {
-	.genpd_name = "SGX",
-	.ch = {
-		.chan_offs = 0xc0, /* PWRSR2 .. PWRER2 */
-		.isr_bit = 20, /* SGX */
-	}
-};
-
-struct r8a7779_pm_domain r8a7779_vdp1 = {
-	.genpd_name = "VDP1",
-	.ch = {
-		.chan_offs = 0x100, /* PWRSR3 .. PWRER3 */
-		.isr_bit = 21, /* VDP */
-	}
-};
+void __init r8a7779_init_pm_domains(void)
+{
+	int j;
 
-struct r8a7779_pm_domain r8a7779_impx3 = {
-	.genpd_name = "IMPX3",
-	.ch = {
-		.chan_offs = 0x140, /* PWRSR4 .. PWRER4 */
-		.isr_bit = 24, /* IMP */
-	}
-};
+	for (j = 0; j < ARRAY_SIZE(r8a7779_pm_domains); j++)
+		r8a7779_init_pm_domain(&r8a7779_pm_domains[j]);
+}
 
 #endif /* CONFIG_PM */
 
Index: linux/arch/arm/mach-shmobile/setup-r8a7779.c
===================================================================
--- linux.orig/arch/arm/mach-shmobile/setup-r8a7779.c
+++ linux/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -251,10 +251,7 @@ void __init r8a7779_add_standard_devices
 #endif
 	r8a7779_pm_init();
 
-	r8a7779_init_pm_domain(&r8a7779_sh4a);
-	r8a7779_init_pm_domain(&r8a7779_sgx);
-	r8a7779_init_pm_domain(&r8a7779_vdp1);
-	r8a7779_init_pm_domain(&r8a7779_impx3);
+	r8a7779_init_pm_domains();
 
 	platform_add_devices(r8a7779_early_devices,
 			    ARRAY_SIZE(r8a7779_early_devices));

[RFC][PATCH 12/14] ARM: shmobile: Make rmobile_init_pm_domain() static

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>

Since rmobile_init_pm_domain() is not called anywhere outside of
arch/arm/mach-shmobile/pm-rmobile.c any more, it can be made static
and its header may be removed from pm-rmobile.h.  Modify the code
accordingly.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 arch/arm/mach-shmobile/include/mach/pm-rmobile.h |    2 --
 arch/arm/mach-shmobile/pm-rmobile.c              |    2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

Index: linux/arch/arm/mach-shmobile/include/mach/pm-rmobile.h
===================================================================
--- linux.orig/arch/arm/mach-shmobile/include/mach/pm-rmobile.h
+++ linux/arch/arm/mach-shmobile/include/mach/pm-rmobile.h
@@ -30,12 +30,10 @@ struct rmobile_pm_domain *to_rmobile_pd(
 }
 
 #ifdef CONFIG_PM
-extern void rmobile_init_pm_domain(struct rmobile_pm_domain *rmobile_pd);
 extern void rmobile_init_domains(struct rmobile_pm_domain domains[], int num);
 extern void rmobile_add_device_to_domain(const char *domain_name,
 					struct platform_device *pdev);
 #else
-#define rmobile_init_pm_domain(pd) do { } while (0)
 #define rmobile_init_domains(domains, num) do { } while (0)
 #define rmobile_add_device_to_domain(name, pdev) do { } while (0)
 #endif /* CONFIG_PM */
Index: linux/arch/arm/mach-shmobile/pm-rmobile.c
===================================================================
--- linux.orig/arch/arm/mach-shmobile/pm-rmobile.c
+++ linux/arch/arm/mach-shmobile/pm-rmobile.c
@@ -134,7 +134,7 @@ static int rmobile_pd_start_dev(struct d
 	return ret;
 }
 
-void rmobile_init_pm_domain(struct rmobile_pm_domain *rmobile_pd)
+static void rmobile_init_pm_domain(struct rmobile_pm_domain *rmobile_pd)
 {
 	struct generic_pm_domain *genpd = &rmobile_pd->genpd;
 	struct dev_power_governor *gov = rmobile_pd->gov;

[RFC][PATCH 13/14] PM / Domains: Introduce pm_genpd_present()

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>

Introduce function pm_genpd_present() allowing the caller to check if
the given generic PM domain has been initialized.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 drivers/base/power/domain.c |   22 ++++++++++++++++++++++
 include/linux/pm_domain.h   |    5 +++++
 2 files changed, 27 insertions(+)

Index: linux/drivers/base/power/domain.c
===================================================================
--- linux.orig/drivers/base/power/domain.c
+++ linux/drivers/base/power/domain.c
@@ -2089,3 +2089,25 @@ void pm_genpd_init(struct generic_pm_dom
 	list_add(&genpd->gpd_list_node, &gpd_list);
 	mutex_unlock(&gpd_list_lock);
 }
+
+/**
+ * pm_genpd_present - Check if the given PM domain has been initialized
+ * @genpd: PM domain to check.
+ */
+bool pm_genpd_present(struct generic_pm_domain *genpd)
+{
+	struct generic_pm_domain *gpd = NULL;
+
+	if (IS_ERR_OR_NULL(genpd))
+		return false;
+
+	mutex_lock(&gpd_list_lock);
+
+	list_for_each_entry(gpd, &gpd_list, gpd_list_node)
+		if (gpd == genpd)
+			break;
+
+	mutex_unlock(&gpd_list_lock);
+
+	return gpd == genpd;
+}
Index: linux/include/linux/pm_domain.h
===================================================================
--- linux.orig/include/linux/pm_domain.h
+++ linux/include/linux/pm_domain.h
@@ -161,6 +161,7 @@ extern int genpd_attach_cpuidle(struct g
 extern int genpd_detach_cpuidle(struct generic_pm_domain *genpd);
 extern void pm_genpd_init(struct generic_pm_domain *genpd,
 			  struct dev_power_governor *gov, bool is_off);
+extern bool pm_genpd_present(struct generic_pm_domain *genpd);
 
 extern int pm_genpd_poweron(struct generic_pm_domain *genpd);
 extern int pm_genpd_name_poweron(const char *domain_name);
@@ -239,6 +240,10 @@ static inline void pm_genpd_init(struct
 				 struct dev_power_governor *gov, bool is_off)
 {
 }
+static inline bool pm_genpd_present(struct generic_pm_domain *genpd)
+{
+	return false;
+}
 static inline int pm_genpd_poweron(struct generic_pm_domain *genpd)
 {
 	return -ENOSYS;

[RFC][PATCH 14/14] ARM: shmobile: Add support for storing PM domain information in DTs

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>

Allow the common power management support code for Renesas SoCs to
read the names of the power domains that platform devices belong to
from a device tree describing the platform.

The name of the power domain is stored within the given device's DT
node as a case-sensitive string attribute of the name
"renesas,pmdomain".  The values of those attributes are read by the
platform code throuch a platform bus type notifier which is executed
right after adding the device to the device hierarchy and are then
used for adding devices to the given PM domains with the help of
pm_genpd_name_add_device().

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 arch/arm/mach-shmobile/pm-rmobile.c |   92 ++++++++++++++++++++++++++++++++----
 1 file changed, 83 insertions(+), 9 deletions(-)

Index: linux/arch/arm/mach-shmobile/pm-rmobile.c
===================================================================
--- linux.orig/arch/arm/mach-shmobile/pm-rmobile.c
+++ linux/arch/arm/mach-shmobile/pm-rmobile.c
@@ -3,6 +3,7 @@
  *
  * Copyright (C) 2012  Renesas Solutions Corp.
  * Copyright (C) 2012  Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+ * Copyright (C) 2012  Rafael J. Wysocki <rjw@sisk.pl>
  *
  * based on pm-sh7372.c
  *  Copyright (C) 2011 Magnus Damm
@@ -13,7 +14,9 @@
  */
 #include <linux/console.h>
 #include <linux/delay.h>
+#include <linux/notifier.h>
 #include <linux/platform_device.h>
+#include <linux/of_platform.h>
 #include <linux/pm.h>
 #include <linux/pm_clock.h>
 #include <asm/io.h>
@@ -149,21 +152,92 @@ static void rmobile_init_pm_domain(struc
 	__rmobile_pd_power_up(rmobile_pd, false);
 }
 
-void rmobile_init_domains(struct rmobile_pm_domain domains[], int num)
-{
-	int j;
-
-	for (j = 0; j < num; j++)
-		rmobile_init_pm_domain(&domains[j]);
-}
-
 void rmobile_add_device_to_domain(const char *domain_name,
 				 struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
+	int ret;
 
-	pm_genpd_name_add_device(domain_name, dev);
+	do
+		ret = pm_genpd_name_add_device(domain_name, dev);
+	while (ret == -EAGAIN);
 	if (pm_clk_no_clocks(dev))
 		pm_clk_add(dev, NULL);
 }
+
+#ifdef CONFIG_USE_OF
+
+static void rmobile_read_domain_from_dt(struct device *dev)
+{
+	const char *domain_name;
+	int ret;
+
+	ret = of_property_read_string(dev->of_node, "renesas,pmdomain",
+				      &domain_name);
+	if (!ret)
+		rmobile_add_device_to_domain(domain_name,
+					     to_platform_device(dev));
+}
+
+static void rmobile_remove_from_domain(struct device *dev)
+{
+	struct generic_pm_domain *genpd = dev_to_genpd(dev);
+	int ret;
+
+	/*
+	 * The check below takes care of the situations in which the device's
+	 * pm_domain pointer contains a valid address, but that is not an
+	 * address of a generic PM domain object.
+	 */
+	if (pm_genpd_present(genpd)) {
+		do
+			ret = pm_genpd_remove_device(genpd, dev);
+		while (ret == -EAGAIN);
+	}
+}
+
+static int rmobile_pm_notifier_call(struct notifier_block *nb,
+				    unsigned long event, void *data)
+{
+	struct device *dev = data;
+
+	switch (event) {
+	case BUS_NOTIFY_ADD_DEVICE:
+		if (dev->of_node)
+			rmobile_read_domain_from_dt(dev);
+
+		break;
+
+	case BUS_NOTIFY_DEL_DEVICE:
+		rmobile_remove_from_domain(dev);
+
+		break;
+	}
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block platform_nb = {
+	.notifier_call = rmobile_pm_notifier_call,
+};
+
+static void rmobile_add_bus_notifier_for_domains(void)
+{
+	bus_register_notifier(&platform_bus_type, &platform_nb);
+}
+
+#else
+
+static inline void rmobile_add_bus_notifier_for_domains(void) {}
+
+#endif /* CONFIG_USE_OF */
+
+void rmobile_init_domains(struct rmobile_pm_domain domains[], int num)
+{
+	int j;
+
+	for (j = 0; j < num; j++)
+		rmobile_init_pm_domain(&domains[j]);
+
+	rmobile_add_bus_notifier_for_domains();
+}
 #endif /* CONFIG_PM */

Re: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)

[Rafael J. Wysocki]

On Monday, July 16, 2012, Rafael J. Wysocki wrote:
> On Thursday, July 05, 2012, Rafael J. Wysocki wrote:
> > On Wednesday, July 04, 2012, Mark Brown wrote:
> > > On Tue, Jul 03, 2012 at 11:02:17PM +0200, Rafael J. Wysocki wrote:
> > > 
> > > > I actually don't have any ideas how to do that at the moment, but I wonder
> > > > if anyone has already thought about it?
> > > 
> > > > For one, I don't think that representing a power domain as a platform device
> > > > would be a good approach and I'm not sure how to represent the relationships
> > > > between devices and the domains they belong to.
> > > 
> > > I guess the OMAP hwmod stuff is the closest thing we've got at the
> > > minute (I don't recall seeing any other implementations in mainline) but
> > > the hwmods themselves don't appear in the DTS right now.  They have a
> > > ti,hwmods property on each device naming the hwmod it's in, something
> > > like that seems like a reasonable approach, possibly a reference to
> > > another DT node rather than or as well as a string?  That seems fairly
> > > easy.
> > 
> > Well, it looks like (and please tell me if I'm wrong) the hwmons are just
> > string attributes that are parsed by the platform-specific code through
> > a platform bus type notifier.
> > 
> > We could do that for power domains too, but then each platform wanting to
> > use them would need to implement such a notifier and add its own routine
> > for parsing those strings.  Would that be acceptable to everyone concerned?
> 
> I tried to follow the above suggestion and prepared the following patchset
> that allows power domain information for Renesas platforms to be passed as
> "renesas,pmdomain" string attribute of device nodes.  It adds functions
> allowing the generic PM domains framework to use names for domain
> identification in various situations and reworks the ARM/shmobile power domains
> support code to used those functions instead of the "raw" ones that take
> domain pointers as their arguments.  Finally, it defines a platform bus type
> notifier that will add devices whose DT nodes contain the "renesas,pmdomain"
> attribute to the power domains indicated by it (the value of that attribute
> should be the name of the PM domain to add the device to after it's been
> registered).  All of this should allow platform devices to be added to
> appropriate power domains automatically based on the information read from
> a DT.
> 
> The patches are on top of the current linux-next tree.
> 
> I've tested the patches that could be tested on the Mackerel board, except
> for the last one (I'm still working on testing it).

Well, no comments, no objections.  Good!

I've just tested [14/14] too and it works as expected.

Thanks,
Rafael

Re: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)

[Arnd Bergmann]

On Saturday 21 July 2012, Rafael J. Wysocki wrote:
> On Monday, July 16, 2012, Rafael J. Wysocki wrote:
> > On Thursday, July 05, 2012, Rafael J. Wysocki wrote:
> > > On Wednesday, July 04, 2012, Mark Brown wrote:
> > > > I guess the OMAP hwmod stuff is the closest thing we've got at the
> > > > minute (I don't recall seeing any other implementations in mainline) but
> > > > the hwmods themselves don't appear in the DTS right now.  They have a
> > > > ti,hwmods property on each device naming the hwmod it's in, something
> > > > like that seems like a reasonable approach, possibly a reference to
> > > > another DT node rather than or as well as a string?  That seems fairly
> > > > easy.
> > > 
> > > Well, it looks like (and please tell me if I'm wrong) the hwmons are just
> > > string attributes that are parsed by the platform-specific code through
> > > a platform bus type notifier.
> > > 
> > > We could do that for power domains too, but then each platform wanting to
> > > use them would need to implement such a notifier and add its own routine
> > > for parsing those strings.  Would that be acceptable to everyone concerned?
> > 
> > I tried to follow the above suggestion and prepared the following patchset
> > that allows power domain information for Renesas platforms to be passed as
> > "renesas,pmdomain" string attribute of device nodes.  It adds functions
> > allowing the generic PM domains framework to use names for domain
> > identification in various situations and reworks the ARM/shmobile power domains
> > support code to used those functions instead of the "raw" ones that take
> > domain pointers as their arguments.  Finally, it defines a platform bus type
> > notifier that will add devices whose DT nodes contain the "renesas,pmdomain"
> > attribute to the power domains indicated by it (the value of that attribute
> > should be the name of the PM domain to add the device to after it's been
> > registered).  All of this should allow platform devices to be added to
> > appropriate power domains automatically based on the information read from
> > a DT.
> > 
> > The patches are on top of the current linux-next tree.
> > 
> > I've tested the patches that could be tested on the Mackerel board, except
> > for the last one (I'm still working on testing it).
> 
> Well, no comments, no objections.  Good!
> 
> I've just tested [14/14] too and it works as expected.

Sorry for taking so long to reply. I am really not that familiar with the
power domain requirements, but I do have two comments on your approach:

* I think when we want to add a generic concept to the device tree such
  as power domains, we should always make it specified in a generic way.
  You have used the "renesas,pmdomain" attribute, which is specific to
  one vendor and requires platform specific code to read it.
  Is there any reason not to put the code into the generic
  drivers/base/power/domain.c file (or near it) and make a binding that
  works for everyone?

* Mark suggested two options (string and phandle), and (you guessed it),
  I would much prefer the other one.
  IMHO using phandle makes it much easier to do this in a generic way,
  without having to document every possible string that this can be
  set to in the binding document. Obviously the phandle requires having
  a node in the device tree for each domain, but I think having that
  node is actually an advantage because it lets you describe the
  hierarchy of the domains there.

	Arnd

Re: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)

[Rafael J. Wysocki]

On Tuesday, July 24, 2012, Arnd Bergmann wrote:
> On Saturday 21 July 2012, Rafael J. Wysocki wrote:
> > On Monday, July 16, 2012, Rafael J. Wysocki wrote:
> > > On Thursday, July 05, 2012, Rafael J. Wysocki wrote:
> > > > On Wednesday, July 04, 2012, Mark Brown wrote:
> > > > > I guess the OMAP hwmod stuff is the closest thing we've got at the
> > > > > minute (I don't recall seeing any other implementations in mainline) but
> > > > > the hwmods themselves don't appear in the DTS right now.  They have a
> > > > > ti,hwmods property on each device naming the hwmod it's in, something
> > > > > like that seems like a reasonable approach, possibly a reference to
> > > > > another DT node rather than or as well as a string?  That seems fairly
> > > > > easy.
> > > > 
> > > > Well, it looks like (and please tell me if I'm wrong) the hwmons are just
> > > > string attributes that are parsed by the platform-specific code through
> > > > a platform bus type notifier.
> > > > 
> > > > We could do that for power domains too, but then each platform wanting to
> > > > use them would need to implement such a notifier and add its own routine
> > > > for parsing those strings.  Would that be acceptable to everyone concerned?
> > > 
> > > I tried to follow the above suggestion and prepared the following patchset
> > > that allows power domain information for Renesas platforms to be passed as
> > > "renesas,pmdomain" string attribute of device nodes.  It adds functions
> > > allowing the generic PM domains framework to use names for domain
> > > identification in various situations and reworks the ARM/shmobile power domains
> > > support code to used those functions instead of the "raw" ones that take
> > > domain pointers as their arguments.  Finally, it defines a platform bus type
> > > notifier that will add devices whose DT nodes contain the "renesas,pmdomain"
> > > attribute to the power domains indicated by it (the value of that attribute
> > > should be the name of the PM domain to add the device to after it's been
> > > registered).  All of this should allow platform devices to be added to
> > > appropriate power domains automatically based on the information read from
> > > a DT.
> > > 
> > > The patches are on top of the current linux-next tree.
> > > 
> > > I've tested the patches that could be tested on the Mackerel board, except
> > > for the last one (I'm still working on testing it).
> > 
> > Well, no comments, no objections.  Good!
> > 
> > I've just tested [14/14] too and it works as expected.
> 
> Sorry for taking so long to reply. I am really not that familiar with the
> power domain requirements, but I do have two comments on your approach:
> 
> * I think when we want to add a generic concept to the device tree such
>   as power domains, we should always make it specified in a generic way.

Do we really want that?  I'm a bit skeptical, because apparently nobody
cares, as the (zero) response to this patchset evidently indicates and
since nobody cares, it's probably better not to add such "generic" things
just yet.

>   You have used the "renesas,pmdomain" attribute, which is specific to
>   one vendor and requires platform specific code to read it.
>   Is there any reason not to put the code into the generic
>   drivers/base/power/domain.c file (or near it) and make a binding that
>   works for everyone?

Yes, there is.  A couple of them in fact.

First off, power domains will always need platform-specific code to support
them, no matter what.  The problem is that they tend to require special
handling, even within the same SoC, let alone different SoCs, and that handling
has to be implemented in an SoC-specific way, because it has to know various
things about the platform (like what to write to what register(s) at what time
and so on).  Of course, that platform-specific code needs to know which
domain the given description corresponds to and there doesn't seem to be any
useful way to specify that through DTs.

Second, the generic code needed to support such a binding would have to be
quite complex and I don't see any advantage from adding it.

Finally, even if I did that, I seriously doubt it would really work for
everyone.  Unfortunately, I have no idea what _everyone's_ needs are,
I only know what the needs of Renesas platforms are, so I went for an
approach limited to those platforms.

> * Mark suggested two options (string and phandle), and (you guessed it),

To me, the Mark's suggestion was to follow the example of TI hwmods, which
I did.  In fact, the power domains on Renesas platforms are an analogous
concept, so in my opinion handling them in analogy with hwmods makes a lot of
sense.

>   I would much prefer the other one.

However, I wouldn't. :-)

>   IMHO using phandle makes it much easier to do this in a generic way,
>   without having to document every possible string that this can be
>   set to in the binding document. Obviously the phandle requires having
>   a node in the device tree for each domain, but I think having that
>   node is actually an advantage because it lets you describe the
>   hierarchy of the domains there.

I don't quite see how it is better.  I could (and should in fact) represent
that hierarchy as an array of pairs of strings without adding any special
parsing code to the kernel (except for a simple routine walking that table
and calling pm_genpd_add_subdomain_names() for every pair).

The only disadvantage of the current approach I can see is that whoever
creates a dts for a board based on the given SoC has to know the names of the
power domains to use in there.  I don't think this is an overly burdensome
requirement.

The other way around, the platform code supposed to handle the power domains
would need a way to match DT nodes against the domains, which also would
require some string-based identification and that would have to be documented
as well.

So no, I don't think using phandles would buy us anything, as of today at least.

Thanks,
Rafael

Re: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)

[Arnd Bergmann]

On Tuesday 24 July 2012, Rafael J. Wysocki wrote:
> On Tuesday, July 24, 2012, Arnd Bergmann wrote:
> > On Saturday 21 July 2012, Rafael J. Wysocki wrote:

> > 
> > Sorry for taking so long to reply. I am really not that familiar with the
> > power domain requirements, but I do have two comments on your approach:
> > 
> > * I think when we want to add a generic concept to the device tree such
> >   as power domains, we should always make it specified in a generic way.
> 
> Do we really want that?  I'm a bit skeptical, because apparently nobody
> cares, as the (zero) response to this patchset evidently indicates and
> since nobody cares, it's probably better not to add such "generic" things
> just yet.

Well, the trouble with bindings is that they are much harder to change
later, at least in incompatible ways. 

> >   You have used the "renesas,pmdomain" attribute, which is specific to
> >   one vendor and requires platform specific code to read it.
> >   Is there any reason not to put the code into the generic
> >   drivers/base/power/domain.c file (or near it) and make a binding that
> >   works for everyone?
> 
> Yes, there is.  A couple of them in fact.
> 
> First off, power domains will always need platform-specific code to support
> them, no matter what.  The problem is that they tend to require special
> handling, even within the same SoC, let alone different SoCs, and that handling
> has to be implemented in an SoC-specific way, because it has to know various
> things about the platform (like what to write to what register(s) at what time
> and so on).  Of course, that platform-specific code needs to know which
> domain the given description corresponds to and there doesn't seem to be any
> useful way to specify that through DTs.

We have the same problem for a lot of other subsystems: clock, regulator,
irq, gpio, pinctrl, dma, ...

In each of these cases, we want a driver to be able to associate some
property with a driver (or platform code) from another subsystem.
We try to handle those using generic subsystem code that interprets
regular property names.

> Second, the generic code needed to support such a binding would have to be
> quite complex and I don't see any advantage from adding it.

The generic binding would only need to specify what the property
looks like and how the possible values can be determined. We don't
need to make that code generic right away but could wait until we
have a couple of implementations before we pull out the common bits.

The important part to me is writing the binding in a way that allows
us to do this.

> 
> > * Mark suggested two options (string and phandle), and (you guessed it),
> 
> To me, the Mark's suggestion was to follow the example of TI hwmods, which
> I did.  In fact, the power domains on Renesas platforms are an analogous
> concept, so in my opinion handling them in analogy with hwmods makes a lot of
> sense.

I had never seen the hwmod binding before and if I had I would have
given them the same comments. I definitely don't think we should be
using it as a good example for common code.

> >   IMHO using phandle makes it much easier to do this in a generic way,
> >   without having to document every possible string that this can be
> >   set to in the binding document. Obviously the phandle requires having
> >   a node in the device tree for each domain, but I think having that
> >   node is actually an advantage because it lets you describe the
> >   hierarchy of the domains there.
> 
> I don't quite see how it is better.  I could (and should in fact) represent
> that hierarchy as an array of pairs of strings without adding any special
> parsing code to the kernel (except for a simple routine walking that table
> and calling pm_genpd_add_subdomain_names() for every pair).
> 
> The only disadvantage of the current approach I can see is that whoever
> creates a dts for a board based on the given SoC has to know the names of the
> power domains to use in there.  I don't think this is an overly burdensome
> requirement.

Well, it does mean that we need to maintain a separate binding document
for each soc that has its own set of possible values.

> The other way around, the platform code supposed to handle the power domains
> would need a way to match DT nodes against the domains, which also would
> require some string-based identification and that would have to be documented
> as well.

The part that matches the pm-domain device nodes can and should be
specific to the platform implementing the pm-domain. We can easily
do the same thing we did for regulators, where each regulator can
be either identified through its "reg" property in cases where that
makes sense or through a "regulator-compatible" property in cases
where we need a string representation.

	Arnd

Re: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)

[Rafael J. Wysocki]

On Tuesday, July 24, 2012, Arnd Bergmann wrote:
> On Tuesday 24 July 2012, Rafael J. Wysocki wrote:
> > On Tuesday, July 24, 2012, Arnd Bergmann wrote:
> > > On Saturday 21 July 2012, Rafael J. Wysocki wrote:
> 
> > > 
> > > Sorry for taking so long to reply. I am really not that familiar with the
> > > power domain requirements, but I do have two comments on your approach:
> > > 
> > > * I think when we want to add a generic concept to the device tree such
> > >   as power domains, we should always make it specified in a generic way.
> > 
> > Do we really want that?  I'm a bit skeptical, because apparently nobody
> > cares, as the (zero) response to this patchset evidently indicates and
> > since nobody cares, it's probably better not to add such "generic" things
> > just yet.
> 
> Well, the trouble with bindings is that they are much harder to change
> later, at least in incompatible ways. 

Hmm, so I think you wanted to say that it might be burdensome to retain the
code handling the old binding once we had started to use a new generic one.

I can agree with that, but that's quite similar to user space interfaces.
Once we've exposed a user space interface of some kind and someone starts
to use it, we'll have to maintain it going forward for the user in question.
However, there is a way to deprecate old user space interfaces and it has
happened.

In this particular case the burden would be on Renesas, but I don't think it
would affect anybody else.

> > >   You have used the "renesas,pmdomain" attribute, which is specific to
> > >   one vendor and requires platform specific code to read it.
> > >   Is there any reason not to put the code into the generic
> > >   drivers/base/power/domain.c file (or near it) and make a binding that
> > >   works for everyone?
> > 
> > Yes, there is.  A couple of them in fact.
> > 
> > First off, power domains will always need platform-specific code to support
> > them, no matter what.  The problem is that they tend to require special
> > handling, even within the same SoC, let alone different SoCs, and that handling
> > has to be implemented in an SoC-specific way, because it has to know various
> > things about the platform (like what to write to what register(s) at what time
> > and so on).  Of course, that platform-specific code needs to know which
> > domain the given description corresponds to and there doesn't seem to be any
> > useful way to specify that through DTs.
> 
> We have the same problem for a lot of other subsystems: clock, regulator,
> irq, gpio, pinctrl, dma, ...
> 
> In each of these cases, we want a driver to be able to associate some
> property with a driver (or platform code) from another subsystem.
> We try to handle those using generic subsystem code that interprets
> regular property names.

For power domains those properties would be SoC-specific.  That is, there may
be a different set of properties for each SoC in principle and it's going to
get quite messy relatively quickly.

> > Second, the generic code needed to support such a binding would have to be
> > quite complex and I don't see any advantage from adding it.
> 
> The generic binding would only need to specify what the property
> looks like and how the possible values can be determined. We don't
> need to make that code generic right away but could wait until we
> have a couple of implementations before we pull out the common bits.
> 
> The important part to me is writing the binding in a way that allows
> us to do this.

Admittedly, I have a little experience with writing DT bindings.

The regulator bindings look like we could do something similar for power
domains, but for one I don't want platform device objects to be created
for them in any case (that would make as much sense as creating a platform
device for a bus type).

> > 
> > > * Mark suggested two options (string and phandle), and (you guessed it),
> > 
> > To me, the Mark's suggestion was to follow the example of TI hwmods, which
> > I did.  In fact, the power domains on Renesas platforms are an analogous
> > concept, so in my opinion handling them in analogy with hwmods makes a lot of
> > sense.
> 
> I had never seen the hwmod binding before and if I had I would have
> given them the same comments. I definitely don't think we should be
> using it as a good example for common code.

Well, good to know. :-)

> > >   IMHO using phandle makes it much easier to do this in a generic way,
> > >   without having to document every possible string that this can be
> > >   set to in the binding document. Obviously the phandle requires having
> > >   a node in the device tree for each domain, but I think having that
> > >   node is actually an advantage because it lets you describe the
> > >   hierarchy of the domains there.
> > 
> > I don't quite see how it is better.  I could (and should in fact) represent
> > that hierarchy as an array of pairs of strings without adding any special
> > parsing code to the kernel (except for a simple routine walking that table
> > and calling pm_genpd_add_subdomain_names() for every pair).
> > 
> > The only disadvantage of the current approach I can see is that whoever
> > creates a dts for a board based on the given SoC has to know the names of the
> > power domains to use in there.  I don't think this is an overly burdensome
> > requirement.
> 
> Well, it does mean that we need to maintain a separate binding document
> for each soc that has its own set of possible values.

I'm not sure we'll be able to avoid that anyway.

> > The other way around, the platform code supposed to handle the power domains
> > would need a way to match DT nodes against the domains, which also would
> > require some string-based identification and that would have to be documented
> > as well.
> 
> The part that matches the pm-domain device nodes can and should be
> specific to the platform implementing the pm-domain. We can easily
> do the same thing we did for regulators, where each regulator can
> be either identified through its "reg" property in cases where that
> makes sense or through a "regulator-compatible" property in cases
> where we need a string representation.

Where can I find the code that parses the regulator bindings?

Rafael

Re: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)

[Rafael J. Wysocki]

On Tuesday, July 24, 2012, Rafael J. Wysocki wrote:
> On Tuesday, July 24, 2012, Arnd Bergmann wrote:
> > On Tuesday 24 July 2012, Rafael J. Wysocki wrote:
> > > On Tuesday, July 24, 2012, Arnd Bergmann wrote:
> > > > On Saturday 21 July 2012, Rafael J. Wysocki wrote:
> > 
> > > > 
> > > > Sorry for taking so long to reply. I am really not that familiar with the
> > > > power domain requirements, but I do have two comments on your approach:
> > > > 
> > > > * I think when we want to add a generic concept to the device tree such
> > > >   as power domains, we should always make it specified in a generic way.
> > > 
> > > Do we really want that?  I'm a bit skeptical, because apparently nobody
> > > cares, as the (zero) response to this patchset evidently indicates and
> > > since nobody cares, it's probably better not to add such "generic" things
> > > just yet.
> > 
> > Well, the trouble with bindings is that they are much harder to change
> > later, at least in incompatible ways. 
> 
> Hmm, so I think you wanted to say that it might be burdensome to retain the
> code handling the old binding once we had started to use a new generic one.
> 
> I can agree with that, but that's quite similar to user space interfaces.
> Once we've exposed a user space interface of some kind and someone starts
> to use it, we'll have to maintain it going forward for the user in question.
> However, there is a way to deprecate old user space interfaces and it has
> happened.
> 
> In this particular case the burden would be on Renesas, but I don't think it
> would affect anybody else.

Whereas, if we go for a generic binding and get it wrong (which is quite
likely, given the general lack of information on what the needs are), we'll
have a much bigger problem that _will_ affect everyone.

So, my opinion is to go for vendor-specific attributes of limited scope for now,
that will be relatively easy to deprecate in the future.

Thanks,
Rafael

Re: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)

[Arnd Bergmann]

On Tuesday 24 July 2012, Rafael J. Wysocki wrote:
> On Tuesday, July 24, 2012, Arnd Bergmann wrote:
> > On Tuesday 24 July 2012, Rafael J. Wysocki wrote:
> > > On Tuesday, July 24, 2012, Arnd Bergmann wrote:
> > > > On Saturday 21 July 2012, Rafael J. Wysocki wrote:
> > 
> > > > 
> > > > Sorry for taking so long to reply. I am really not that familiar with the
> > > > power domain requirements, but I do have two comments on your approach:
> > > > 
> > > > * I think when we want to add a generic concept to the device tree such
> > > >   as power domains, we should always make it specified in a generic way.
> > > 
> > > Do we really want that?  I'm a bit skeptical, because apparently nobody
> > > cares, as the (zero) response to this patchset evidently indicates and
> > > since nobody cares, it's probably better not to add such "generic" things
> > > just yet.
> > 
> > Well, the trouble with bindings is that they are much harder to change
> > later, at least in incompatible ways. 
> 
> Hmm, so I think you wanted to say that it might be burdensome to retain the
> code handling the old binding once we had started to use a new generic one.
> 
> I can agree with that, but that's quite similar to user space interfaces.
> Once we've exposed a user space interface of some kind and someone starts
> to use it, we'll have to maintain it going forward for the user in question.
> However, there is a way to deprecate old user space interfaces and it has
> happened.
> 
> In this particular case the burden would be on Renesas, but I don't think it
> would affect anybody else.

[adding devicetree-discuss@lists.ozlabs.org]

In case of user space interfaces, we also try very hard to avoid cases
where we know that we will have to change things later.

I don't think it's that hard to define a generic binding here, we just
need to make sure it's extensible.

One thing I would like to avoid is having to add to every single
device binding two separate optional properties defined like

diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt
index 2b584ca..353152e 100644
--- a/Documentation/devicetree/bindings/mmc/mmci.txt
+++ b/Documentation/devicetree/bindings/mmc/mmci.txt
@@ -13,3 +13,9 @@ Required properties:
 Optional properties:
 - mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable
 - mmc-cap-sd-highspeed   : indicates whether SD is high speed capable
+- pm-domain		 : a phandle pointing to the power domain
+			   controlling this device
+			   See ../pm-domain/generic.txt
+- renesas,pm-domain	 : a string with the name of the power domain
+			   controlling this device.
+			   See ../pm-domain/renesas.txt

Even if you say that the burden is only on Renesas to maintain all those
changes to every binding they use, there is also a burden on people trying
to understand the binding and deciding which one to use.

> > > >   You have used the "renesas,pmdomain" attribute, which is specific to
> > > >   one vendor and requires platform specific code to read it.
> > > >   Is there any reason not to put the code into the generic
> > > >   drivers/base/power/domain.c file (or near it) and make a binding that
> > > >   works for everyone?
> > > 
> > > Yes, there is.  A couple of them in fact.
> > > 
> > > First off, power domains will always need platform-specific code to support
> > > them, no matter what.  The problem is that they tend to require special
> > > handling, even within the same SoC, let alone different SoCs, and that handling
> > > has to be implemented in an SoC-specific way, because it has to know various
> > > things about the platform (like what to write to what register(s) at what time
> > > and so on).  Of course, that platform-specific code needs to know which
> > > domain the given description corresponds to and there doesn't seem to be any
> > > useful way to specify that through DTs.
> > 
> > We have the same problem for a lot of other subsystems: clock, regulator,
> > irq, gpio, pinctrl, dma, ...
> > 
> > In each of these cases, we want a driver to be able to associate some
> > property with a driver (or platform code) from another subsystem.
> > We try to handle those using generic subsystem code that interprets
> > regular property names.
> 
> For power domains those properties would be SoC-specific.  That is, there may
> be a different set of properties for each SoC in principle and it's going to
> get quite messy relatively quickly.

I don't see how power domains are any different from the other cases
I listed. The differences should be contained in whatever provides
the domains. For a device that is part of a power domain, you only need
to know how to find that domain, not what that information means.

> > > Second, the generic code needed to support such a binding would have to be
> > > quite complex and I don't see any advantage from adding it.
> > 
> > The generic binding would only need to specify what the property
> > looks like and how the possible values can be determined. We don't
> > need to make that code generic right away but could wait until we
> > have a couple of implementations before we pull out the common bits.
> > 
> > The important part to me is writing the binding in a way that allows
> > us to do this.
> 
> Admittedly, I have a little experience with writing DT bindings.
> 
> The regulator bindings look like we could do something similar for power
> domains, but for one I don't want platform device objects to be created
> for them in any case (that would make as much sense as creating a platform
> device for a bus type).

We have lots of device nodes in the device tree that do not get
added as platform devices in Linux, and they are used for all sorts
of purposes. For instance most buses (amba, pci, usb, i2c, spi, ...)
can have their devices represented in the device tree but register
their own devices rather than platform devices.

Other nodes are used internally in some code and have no "device"
associated at all. Examples for these are parts of the system that
we don't treat as devices in Linux (cpu, memory, command line)
and things that are subsystem specific but structured (regulators,
pincontrol, clock).

> > > > * Mark suggested two options (string and phandle), and (you guessed it),
> > > 
> > > To me, the Mark's suggestion was to follow the example of TI hwmods, which
> > > I did.  In fact, the power domains on Renesas platforms are an analogous
> > > concept, so in my opinion handling them in analogy with hwmods makes a lot of
> > > sense.
> > 
> > I had never seen the hwmod binding before and if I had I would have
> > given them the same comments. I definitely don't think we should be
> > using it as a good example for common code.
> 
> Well, good to know. :-)
> 
> > > >   IMHO using phandle makes it much easier to do this in a generic way,
> > > >   without having to document every possible string that this can be
> > > >   set to in the binding document. Obviously the phandle requires having
> > > >   a node in the device tree for each domain, but I think having that
> > > >   node is actually an advantage because it lets you describe the
> > > >   hierarchy of the domains there.
> > > 
> > > I don't quite see how it is better.  I could (and should in fact) represent
> > > that hierarchy as an array of pairs of strings without adding any special
> > > parsing code to the kernel (except for a simple routine walking that table
> > > and calling pm_genpd_add_subdomain_names() for every pair).
> > > 
> > > The only disadvantage of the current approach I can see is that whoever
> > > creates a dts for a board based on the given SoC has to know the names of the
> > > power domains to use in there.  I don't think this is an overly burdensome
> > > requirement.
> > 
> > Well, it does mean that we need to maintain a separate binding document
> > for each soc that has its own set of possible values.
> 
> I'm not sure we'll be able to avoid that anyway.

True, but a different kind of document.

The difference is that when using a string, each binding for a device that
can be part of a domain should have a way to document which strings are
possible for the property.
If you use a phandle, the binding for that device just needs to document
that it's a phandle that points to another device for which a binding
exists.
The binding for the SoC can then describe the power domains in a way
that is detached from the devices.

> > > The other way around, the platform code supposed to handle the power domains
> > > would need a way to match DT nodes against the domains, which also would
> > > require some string-based identification and that would have to be documented
> > > as well.
> > 
> > The part that matches the pm-domain device nodes can and should be
> > specific to the platform implementing the pm-domain. We can easily
> > do the same thing we did for regulators, where each regulator can
> > be either identified through its "reg" property in cases where that
> > makes sense or through a "regulator-compatible" property in cases
> > where we need a string representation.
> 
> Where can I find the code that parses the regulator bindings?

The binding is in Documentation/devicetree/bindings/regulator/regulator.txt
and the code is in drivers/regulator/of_regulator.c. Note that this
has recently been extended, so be sure to look at the latest snapshot in
git, not the v3.5 version.

	Arnd

Re: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)

[Rafael J. Wysocki]

On Wednesday, July 25, 2012, Arnd Bergmann wrote:
> On Tuesday 24 July 2012, Rafael J. Wysocki wrote:
> > On Tuesday, July 24, 2012, Arnd Bergmann wrote:
> > > On Tuesday 24 July 2012, Rafael J. Wysocki wrote:
> > > > On Tuesday, July 24, 2012, Arnd Bergmann wrote:
> > > > > On Saturday 21 July 2012, Rafael J. Wysocki wrote:
> > > 
> > > > > 
> > > > > Sorry for taking so long to reply. I am really not that familiar with the
> > > > > power domain requirements, but I do have two comments on your approach:
> > > > > 
> > > > > * I think when we want to add a generic concept to the device tree such
> > > > >   as power domains, we should always make it specified in a generic way.
> > > > 
> > > > Do we really want that?  I'm a bit skeptical, because apparently nobody
> > > > cares, as the (zero) response to this patchset evidently indicates and
> > > > since nobody cares, it's probably better not to add such "generic" things
> > > > just yet.
> > > 
> > > Well, the trouble with bindings is that they are much harder to change
> > > later, at least in incompatible ways. 
> > 
> > Hmm, so I think you wanted to say that it might be burdensome to retain the
> > code handling the old binding once we had started to use a new generic one.
> > 
> > I can agree with that, but that's quite similar to user space interfaces.
> > Once we've exposed a user space interface of some kind and someone starts
> > to use it, we'll have to maintain it going forward for the user in question.
> > However, there is a way to deprecate old user space interfaces and it has
> > happened.
> > 
> > In this particular case the burden would be on Renesas, but I don't think it
> > would affect anybody else.
> 
> [adding devicetree-discuss@lists.ozlabs.org]
> 
> In case of user space interfaces, we also try very hard to avoid cases
> where we know that we will have to change things later.

[Cough, cough]  Yeah, sure.  Except that that's rather difficult to anticipate
usually.

> I don't think it's that hard to define a generic binding here, we just
> need to make sure it's extensible.
> 
> One thing I would like to avoid is having to add to every single
> device binding two separate optional properties defined like
> 
> diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt
> index 2b584ca..353152e 100644
> --- a/Documentation/devicetree/bindings/mmc/mmci.txt
> +++ b/Documentation/devicetree/bindings/mmc/mmci.txt
> @@ -13,3 +13,9 @@ Required properties:
>  Optional properties:
>  - mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable
>  - mmc-cap-sd-highspeed   : indicates whether SD is high speed capable
> +- pm-domain		 : a phandle pointing to the power domain
> +			   controlling this device
> +			   See ../pm-domain/generic.txt
> +- renesas,pm-domain	 : a string with the name of the power domain
> +			   controlling this device.
> +			   See ../pm-domain/renesas.txt
> 
> Even if you say that the burden is only on Renesas to maintain all those
> changes to every binding they use, there is also a burden on people trying
> to understand the binding and deciding which one to use.

What about (tongue in cheek) "renesas,hwmod", then?  That won't be confused
with the generic "pm-domain" in any way, will it?  And since TI did that, we
surely should be allowed to do it as well, no?

Seriously, I'm not fundamentally opposed to using phandles for that in analogy
with regulators, but I'm afraid we won't get it right from the start and it
will turn out that we need to change the definition of the binding somehow
and _that_ is going to be painful.  Pretty much like changing generic user
space interfaces is (as opposed to changing interfaces of limited scope).

However, if that route is taken, I'll expect you to require TI to change their
hwmod binding in the analogous way.

> > > > >   You have used the "renesas,pmdomain" attribute, which is specific to
> > > > >   one vendor and requires platform specific code to read it.
> > > > >   Is there any reason not to put the code into the generic
> > > > >   drivers/base/power/domain.c file (or near it) and make a binding that
> > > > >   works for everyone?
> > > > 
> > > > Yes, there is.  A couple of them in fact.
> > > > 
> > > > First off, power domains will always need platform-specific code to support
> > > > them, no matter what.  The problem is that they tend to require special
> > > > handling, even within the same SoC, let alone different SoCs, and that handling
> > > > has to be implemented in an SoC-specific way, because it has to know various
> > > > things about the platform (like what to write to what register(s) at what time
> > > > and so on).  Of course, that platform-specific code needs to know which
> > > > domain the given description corresponds to and there doesn't seem to be any
> > > > useful way to specify that through DTs.
> > > 
> > > We have the same problem for a lot of other subsystems: clock, regulator,
> > > irq, gpio, pinctrl, dma, ...
> > > 
> > > In each of these cases, we want a driver to be able to associate some
> > > property with a driver (or platform code) from another subsystem.
> > > We try to handle those using generic subsystem code that interprets
> > > regular property names.
> > 
> > For power domains those properties would be SoC-specific.  That is, there may
> > be a different set of properties for each SoC in principle and it's going to
> > get quite messy relatively quickly.
> 
> I don't see how power domains are any different from the other cases
> I listed. The differences should be contained in whatever provides
> the domains. For a device that is part of a power domain, you only need
> to know how to find that domain, not what that information means.

For a device that belongs to a power domain all is trivial pretty much in any
case.  For platform code supposed to operate the domains the situation is
quite different, though.

Suppose that there is a power domain that needs some special handling and
we have a definition in a DT like:

xyz: pm-domain@0 {
                pm-domain-name = "XYZ";
                ...
        };

Now, obviously, the platform code has to figure out that this definition
corresponds to the "special" domain.  What is your suggestion in that respect?
Should we introduce a "pm-this-domain-requires-this-and-that" attribute (that's
not going to be portable between SoCs most likely) or should the platform code
use the domain name or something different?

> > > > Second, the generic code needed to support such a binding would have to be
> > > > quite complex and I don't see any advantage from adding it.
> > > 
> > > The generic binding would only need to specify what the property
> > > looks like and how the possible values can be determined. We don't
> > > need to make that code generic right away but could wait until we
> > > have a couple of implementations before we pull out the common bits.
> > > 
> > > The important part to me is writing the binding in a way that allows
> > > us to do this.
> > 
> > Admittedly, I have a little experience with writing DT bindings.
> > 
> > The regulator bindings look like we could do something similar for power
> > domains, but for one I don't want platform device objects to be created
> > for them in any case (that would make as much sense as creating a platform
> > device for a bus type).
> 
> We have lots of device nodes in the device tree that do not get
> added as platform devices in Linux, and they are used for all sorts
> of purposes. For instance most buses (amba, pci, usb, i2c, spi, ...)
> can have their devices represented in the device tree but register
> their own devices rather than platform devices.
> 
> Other nodes are used internally in some code and have no "device"
> associated at all. Examples for these are parts of the system that
> we don't treat as devices in Linux (cpu, memory, command line)
> and things that are subsystem specific but structured (regulators,
> pincontrol, clock).

As I said, regulators seem to be something we can follow.

> > > > > * Mark suggested two options (string and phandle), and (you guessed it),
> > > > 
> > > > To me, the Mark's suggestion was to follow the example of TI hwmods, which
> > > > I did.  In fact, the power domains on Renesas platforms are an analogous
> > > > concept, so in my opinion handling them in analogy with hwmods makes a lot of
> > > > sense.
> > > 
> > > I had never seen the hwmod binding before and if I had I would have
> > > given them the same comments. I definitely don't think we should be
> > > using it as a good example for common code.
> > 
> > Well, good to know. :-)
> > 
> > > > >   IMHO using phandle makes it much easier to do this in a generic way,
> > > > >   without having to document every possible string that this can be
> > > > >   set to in the binding document. Obviously the phandle requires having
> > > > >   a node in the device tree for each domain, but I think having that
> > > > >   node is actually an advantage because it lets you describe the
> > > > >   hierarchy of the domains there.
> > > > 
> > > > I don't quite see how it is better.  I could (and should in fact) represent
> > > > that hierarchy as an array of pairs of strings without adding any special
> > > > parsing code to the kernel (except for a simple routine walking that table
> > > > and calling pm_genpd_add_subdomain_names() for every pair).
> > > > 
> > > > The only disadvantage of the current approach I can see is that whoever
> > > > creates a dts for a board based on the given SoC has to know the names of the
> > > > power domains to use in there.  I don't think this is an overly burdensome
> > > > requirement.
> > > 
> > > Well, it does mean that we need to maintain a separate binding document
> > > for each soc that has its own set of possible values.
> > 
> > I'm not sure we'll be able to avoid that anyway.
> 
> True, but a different kind of document.
> 
> The difference is that when using a string, each binding for a device that
> can be part of a domain should have a way to document which strings are
> possible for the property.
> If you use a phandle, the binding for that device just needs to document
> that it's a phandle that points to another device for which a binding
> exists.
> The binding for the SoC can then describe the power domains in a way
> that is detached from the devices.

Well, this is much too vague to be useful for me, sorry.

> > > > The other way around, the platform code supposed to handle the power domains
> > > > would need a way to match DT nodes against the domains, which also would
> > > > require some string-based identification and that would have to be documented
> > > > as well.
> > > 
> > > The part that matches the pm-domain device nodes can and should be
> > > specific to the platform implementing the pm-domain. We can easily
> > > do the same thing we did for regulators, where each regulator can
> > > be either identified through its "reg" property in cases where that
> > > makes sense or through a "regulator-compatible" property in cases
> > > where we need a string representation.
> > 
> > Where can I find the code that parses the regulator bindings?
> 
> The binding is in Documentation/devicetree/bindings/regulator/regulator.txt
> and the code is in drivers/regulator/of_regulator.c. Note that this
> has recently been extended, so be sure to look at the latest snapshot in
> git, not the v3.5 version.

I'm rather interested in the code that processes those bindings, but I guess
I'll need to find it myself.  I'm not sure if my determination is sufficient
to deal with all that at the moment, though, but that's a different matter.

Thanks,
Rafael

Re: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)

[Kevin Hilman]

"Rafael J. Wysocki" <rjw@sisk.pl> writes:

> On Wednesday, July 25, 2012, Arnd Bergmann wrote:
>> On Tuesday 24 July 2012, Rafael J. Wysocki wrote:
>> > On Tuesday, July 24, 2012, Arnd Bergmann wrote:
>> > > On Tuesday 24 July 2012, Rafael J. Wysocki wrote:
>> > > > On Tuesday, July 24, 2012, Arnd Bergmann wrote:
>> > > > > On Saturday 21 July 2012, Rafael J. Wysocki wrote:
>> > > 
>> > > > > 
>> > > > > Sorry for taking so long to reply. I am really not that familiar with the
>> > > > > power domain requirements, but I do have two comments on your approach:
>> > > > > 
>> > > > > * I think when we want to add a generic concept to the device tree such
>> > > > >   as power domains, we should always make it specified in a generic way.
>> > > > 
>> > > > Do we really want that?  I'm a bit skeptical, because apparently nobody
>> > > > cares, as the (zero) response to this patchset evidently indicates and
>> > > > since nobody cares, it's probably better not to add such "generic" things
>> > > > just yet.

Sorry to jump in late, but it's been another busy dev cycle and I
haven't had the time to look at this series in detail.  But just so you
know that somebody cares, we're also interested in bindings that will be
useful on other SoCs for PM domains.

However, since OMAP powerdomain support pre-dates generic powerdomains ,
the "generic" power domains aren't quite generic enough get for OMAP,
and I haven't had the time to extend the generic code, we haven't yet
moved to generic powerdomains.

>> > > 
>> > > Well, the trouble with bindings is that they are much harder to change
>> > > later, at least in incompatible ways. 
>> > 
>> > Hmm, so I think you wanted to say that it might be burdensome to retain the
>> > code handling the old binding once we had started to use a new generic one.
>> > 
>> > I can agree with that, but that's quite similar to user space interfaces.
>> > Once we've exposed a user space interface of some kind and someone starts
>> > to use it, we'll have to maintain it going forward for the user in question.
>> > However, there is a way to deprecate old user space interfaces and it has
>> > happened.
>> > 
>> > In this particular case the burden would be on Renesas, but I don't think it
>> > would affect anybody else.
>> 
>> [adding devicetree-discuss@lists.ozlabs.org]
>> 
>> In case of user space interfaces, we also try very hard to avoid cases
>> where we know that we will have to change things later.
>
> [Cough, cough]  Yeah, sure.  Except that that's rather difficult to anticipate
> usually.
>
>> I don't think it's that hard to define a generic binding here, we just
>> need to make sure it's extensible.
>> 
>> One thing I would like to avoid is having to add to every single
>> device binding two separate optional properties defined like
>> 
>> diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt
>> index 2b584ca..353152e 100644
>> --- a/Documentation/devicetree/bindings/mmc/mmci.txt
>> +++ b/Documentation/devicetree/bindings/mmc/mmci.txt
>> @@ -13,3 +13,9 @@ Required properties:
>>  Optional properties:
>>  - mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable
>>  - mmc-cap-sd-highspeed   : indicates whether SD is high speed capable
>> +- pm-domain		 : a phandle pointing to the power domain
>> +			   controlling this device
>> +			   See ../pm-domain/generic.txt
>> +- renesas,pm-domain	 : a string with the name of the power domain
>> +			   controlling this device.
>> +			   See ../pm-domain/renesas.txt
>> 
>> Even if you say that the burden is only on Renesas to maintain all those
>> changes to every binding they use, there is also a burden on people trying
>> to understand the binding and deciding which one to use.
>
> What about (tongue in cheek) "renesas,hwmod", then?  That won't be confused
> with the generic "pm-domain" in any way, will it?  And since TI did that, we
> surely should be allowed to do it as well, no?
>
> Seriously, I'm not fundamentally opposed to using phandles for that in analogy
> with regulators, but I'm afraid we won't get it right from the start and it
> will turn out that we need to change the definition of the binding somehow
> and _that_ is going to be painful.  Pretty much like changing generic user
> space interfaces is (as opposed to changing interfaces of limited scope).
>
> However, if that route is taken, I'll expect you to require TI to change their
> hwmod binding in the analogous way.

FWIW, we're already working on making ti,hwmods disappear.  That was a
temporary step to allow us to easily migrate to DT using our existing,
in-tree description of device IP blocks (hwmods.)

That being said, I'm not sure why ti,hwmods is being used as an example
for powerdomains.  hwmods describe the integration of SoC IP blocks
(base addr, IRQ, DMA channel etc., which are being moved to DT) as well
as a bunch of SoC specific PM register descriptions.  This stuff is
SoC-specific PM register layout, so being very SoC specific, it has the
'ti' prefix in the DT binding.

Anyways, I hope to have a closer look this week, and I know Benoit
Cousson (CC'd) has some ideas for DT bindings for power domains as well.
Unfortunately, he's out until next week.

Kevin

Re: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)

[Rafael J. Wysocki]

On Thursday, July 26, 2012, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> 
> > On Wednesday, July 25, 2012, Arnd Bergmann wrote:
> >> On Tuesday 24 July 2012, Rafael J. Wysocki wrote:
> >> > On Tuesday, July 24, 2012, Arnd Bergmann wrote:
> >> > > On Tuesday 24 July 2012, Rafael J. Wysocki wrote:
> >> > > > On Tuesday, July 24, 2012, Arnd Bergmann wrote:
> >> > > > > On Saturday 21 July 2012, Rafael J. Wysocki wrote:
> >> > > 
> >> > > > > 
> >> > > > > Sorry for taking so long to reply. I am really not that familiar with the
> >> > > > > power domain requirements, but I do have two comments on your approach:
> >> > > > > 
> >> > > > > * I think when we want to add a generic concept to the device tree such
> >> > > > >   as power domains, we should always make it specified in a generic way.
> >> > > > 
> >> > > > Do we really want that?  I'm a bit skeptical, because apparently nobody
> >> > > > cares, as the (zero) response to this patchset evidently indicates and
> >> > > > since nobody cares, it's probably better not to add such "generic" things
> >> > > > just yet.
> 
> Sorry to jump in late, but it's been another busy dev cycle and I
> haven't had the time to look at this series in detail.  But just so you
> know that somebody cares, we're also interested in bindings that will be
> useful on other SoCs for PM domains.
> 
> However, since OMAP powerdomain support pre-dates generic powerdomains ,
> the "generic" power domains aren't quite generic enough get for OMAP,
> and I haven't had the time to extend the generic code, we haven't yet
> moved to generic powerdomains.
> 
> >> > > 
> >> > > Well, the trouble with bindings is that they are much harder to change
> >> > > later, at least in incompatible ways. 
> >> > 
> >> > Hmm, so I think you wanted to say that it might be burdensome to retain the
> >> > code handling the old binding once we had started to use a new generic one.
> >> > 
> >> > I can agree with that, but that's quite similar to user space interfaces.
> >> > Once we've exposed a user space interface of some kind and someone starts
> >> > to use it, we'll have to maintain it going forward for the user in question.
> >> > However, there is a way to deprecate old user space interfaces and it has
> >> > happened.
> >> > 
> >> > In this particular case the burden would be on Renesas, but I don't think it
> >> > would affect anybody else.
> >> 
> >> [adding devicetree-discuss@lists.ozlabs.org]
> >> 
> >> In case of user space interfaces, we also try very hard to avoid cases
> >> where we know that we will have to change things later.
> >
> > [Cough, cough]  Yeah, sure.  Except that that's rather difficult to anticipate
> > usually.
> >
> >> I don't think it's that hard to define a generic binding here, we just
> >> need to make sure it's extensible.
> >> 
> >> One thing I would like to avoid is having to add to every single
> >> device binding two separate optional properties defined like
> >> 
> >> diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt
> >> index 2b584ca..353152e 100644
> >> --- a/Documentation/devicetree/bindings/mmc/mmci.txt
> >> +++ b/Documentation/devicetree/bindings/mmc/mmci.txt
> >> @@ -13,3 +13,9 @@ Required properties:
> >>  Optional properties:
> >>  - mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable
> >>  - mmc-cap-sd-highspeed   : indicates whether SD is high speed capable
> >> +- pm-domain		 : a phandle pointing to the power domain
> >> +			   controlling this device
> >> +			   See ../pm-domain/generic.txt
> >> +- renesas,pm-domain	 : a string with the name of the power domain
> >> +			   controlling this device.
> >> +			   See ../pm-domain/renesas.txt
> >> 
> >> Even if you say that the burden is only on Renesas to maintain all those
> >> changes to every binding they use, there is also a burden on people trying
> >> to understand the binding and deciding which one to use.
> >
> > What about (tongue in cheek) "renesas,hwmod", then?  That won't be confused
> > with the generic "pm-domain" in any way, will it?  And since TI did that, we
> > surely should be allowed to do it as well, no?
> >
> > Seriously, I'm not fundamentally opposed to using phandles for that in analogy
> > with regulators, but I'm afraid we won't get it right from the start and it
> > will turn out that we need to change the definition of the binding somehow
> > and _that_ is going to be painful.  Pretty much like changing generic user
> > space interfaces is (as opposed to changing interfaces of limited scope).
> >
> > However, if that route is taken, I'll expect you to require TI to change their
> > hwmod binding in the analogous way.
> 
> FWIW, we're already working on making ti,hwmods disappear.  That was a
> temporary step to allow us to easily migrate to DT using our existing,
> in-tree description of device IP blocks (hwmods.)

I see.  Obviously I didn't know that. :-)

> That being said, I'm not sure why ti,hwmods is being used as an example
> for powerdomains.  hwmods describe the integration of SoC IP blocks
> (base addr, IRQ, DMA channel etc., which are being moved to DT) as well
> as a bunch of SoC specific PM register descriptions.  This stuff is
> SoC-specific PM register layout, so being very SoC specific, it has the
> 'ti' prefix in the DT binding.
> 
> Anyways, I hope to have a closer look this week, and I know Benoit
> Cousson (CC'd) has some ideas for DT bindings for power domains as well.
> Unfortunately, he's out until next week.

No stress, I won't have the time to look into this again any time soon,
perhaps not even before San Diego.

Thanks,
Rafael

Re: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

On Wed, Jul 25, 2012 at 05:38:35PM -0700, Kevin Hilman wrote:

> That being said, I'm not sure why ti,hwmods is being used as an example
> for powerdomains.  hwmods describe the integration of SoC IP blocks
> (base addr, IRQ, DMA channel etc., which are being moved to DT) as well
> as a bunch of SoC specific PM register descriptions.  This stuff is
> SoC-specific PM register layout, so being very SoC specific, it has the
> 'ti' prefix in the DT binding.

I think the thing here is that one aspect of that SoC integration is
which power domain the blocks are in.  Describing which power domain an
IP is in isn't a million miles away from describing which hwmod applies
to an IP.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)

[Rafael J. Wysocki]

On Thursday, July 26, 2012, Mark Brown wrote:
> On Wed, Jul 25, 2012 at 05:38:35PM -0700, Kevin Hilman wrote:
> 
> > That being said, I'm not sure why ti,hwmods is being used as an example
> > for powerdomains.  hwmods describe the integration of SoC IP blocks
> > (base addr, IRQ, DMA channel etc., which are being moved to DT) as well
> > as a bunch of SoC specific PM register descriptions.  This stuff is
> > SoC-specific PM register layout, so being very SoC specific, it has the
> > 'ti' prefix in the DT binding.
> 
> I think the thing here is that one aspect of that SoC integration is
> which power domain the blocks are in.  Describing which power domain an
> IP is in isn't a million miles away from describing which hwmod applies
> to an IP.

I agree.

Re: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)

[Kevin Hilman]

Mark Brown <broonie@opensource.wolfsonmicro.com> writes:

> On Wed, Jul 25, 2012 at 05:38:35PM -0700, Kevin Hilman wrote:
>
>> That being said, I'm not sure why ti,hwmods is being used as an example
>> for powerdomains.  hwmods describe the integration of SoC IP blocks
>> (base addr, IRQ, DMA channel etc., which are being moved to DT) as well
>> as a bunch of SoC specific PM register descriptions.  This stuff is
>> SoC-specific PM register layout, so being very SoC specific, it has the
>> 'ti' prefix in the DT binding.
>
> I think the thing here is that one aspect of that SoC integration is
> which power domain the blocks are in.  Describing which power domain an
> IP is in isn't a million miles away from describing which hwmod applies
> to an IP.

Not a million miles, just a million transistors. ;)

Ideally, we will eventually have a representation that can map
from regulators all the way down to IP blocks.  regulator --> voltage
domain --> power domain --> clock domain --> clocks --> IP block.

Currently we have bindings for regulators,  IP blocks (ti,hwmods on
OMAP) and clocks are in progress.  Eventually, we'll need everything
else in between.

Kevin

Re: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 498 bytes --]

On Thu, Jul 26, 2012 at 02:45:52PM -0700, Kevin Hilman wrote:

> Ideally, we will eventually have a representation that can map
> from regulators all the way down to IP blocks.  regulator --> voltage
> domain --> power domain --> clock domain --> clocks --> IP block.

Well, often the clock bit is something of a noop - a lot of SoCs can
reparent the IP block clocks between the different clock domains happily
and have core clock domains that are mostly orthogonal to the power
domains.  But yes.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]