Add generic PM domain support for Tegra

Commit 30e7a65b3fdb ("PM / Domains: Ensure subdomain is not in use before removing") added a test to ensure that a subdomain is not is not

a master to another subdomain or if any devices are using the subdomain before removing. This change incorrectly used the "slave_links" list to determine if the subdomain is a master to another subdomain, where it should have been using the "master_links" list instead. The "slave_links" list will never be empty for a subdomain and so a subdomain can never be removed. Fix this by testing if the "master_links" list is empty instead.

Fixes 30e7a65b3fdb ("PM / Domains: Ensure subdomain is not in use

before removing")

Signed-off-by Jon Hunter <[email protected]>

---
 drivers/base/power/domain.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/base/power/domain.c +1 -1

index e8ca290dbf9d..ea9f2aa3fc33 100644
@@ -1382,7 +1382,7 @@ int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
 	mutex_lock(&subdomain->lock);
 	mutex_lock_nested(&genpd->lock, SINGLE_DEPTH_NESTING);
 
-	if (!list_empty(&subdomain->slave_links) || subdomain->device_count) {
+	if (!list_empty(&subdomain->master_links) || subdomain->device_count) {
 		pr_warn("%s: unable to remove subdomain %s\n", genpd->name,
 			subdomain->name);
 		ret = -EBUSY;

Signature · 1 line

2.1.4

Commit 30e7a65b3fdb ("PM / Domains: Ensure subdomain is not in use before removing") added a test to ensure that a subdomain is not is not a master to another subdomain or if any devices are using the subdomain before removing. This change incorrectly used the "slave_links" list to determine if the subdomain is a master to another subdomain, where it should have been using the "master_links" list instead. The "slave_links" list will never be empty for a subdomain and so a subdomain can never be removed. Fix this by testing if the "master_links" list is empty instead.

Fixes 30e7a65b3fdb ("PM / Domains: Ensure subdomain is not in use

before removing")

Signed-off-by Jon Hunter <[email protected]>

---
 drivers/base/power/domain.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/base/power/domain.c +1 -2

index e8ca290dbf9d..ea9f2aa3fc33 100644
@@ -1382,7 +1382,7 @@ int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
        mutex_lock(&subdomain->lock);
        mutex_lock_nested(&genpd->lock, SINGLE_DEPTH_NESTING);
 
-       if (!list_empty(&subdomain->slave_links) || subdomain->device_count) {
+       if (!list_empty(&subdomain->master_links) || subdomain->device_count) {
                pr_warn("%s: unable to remove subdomain %s\n", genpd->name,
                        subdomain->name);
                ret = -EBUSY;
--

2.1.4

The genpd framework allows users to add power-domains via the pm_genpd_init() function, however, there is no corresponding function to remove a power-domain. For most devices this may be fine as the power domains are never removed, however, for devices that wish to populate the power-domains from within a driver, having the ability to remove a power domain if the probing of the device fails or the driver is unloaded is necessary. Therefore, add a function to remove a power-domain. Please note that the power domain can only be removed if there are no devices using the power-domain and it is not linked to another domain.

Signed-off-by Jon Hunter <[email protected]>

---
 drivers/base/power/domain.c | 31 +++++++++++++++++++++++++++++++
 include/linux/pm_domain.h   |  5 +++++
 2 files changed, 36 insertions(+)

drivers/base/power/domain.c +0 -0

index 608bc00655ee..22f6e9d738bf 100644

* PGP Signed by an unknown key

Quoted 9 lines · Jon Hunter

The genpd framework allows users to add power-domains via the pm_genpd_init() function, however, there is no corresponding function to remove a power-domain. For most devices this may be fine as the power domains are never removed, however, for devices that wish to populate the power-domains from within a driver, having the ability to remove a power domain if the probing of the device fails or the driver is unloaded is necessary. Therefore, add a function to remove a power-domain. Please note that the power domain can only be removed if there are no devices using the power-domain and it is not linked to another domain.

So I guess this introduces a problem not uncommon to other types of resources. If you remove the driver, even if you fail ->remove() the module may still go away along with any code associated with it. So even if the PM domains can't be removed, you can't prevent the module from going away. That could be somewhat mitigated if we were holding a module reference count, because then the only way to unload the driver would be via sysfs (we could prevent that too, which might be the best way to do this today).

There is work underway to solve this generically, Rafael was working on this, so I'm not sure we need to add additional infrastructure to the PM domain code as part of this series. But we may want to mark the Tegra PMC driver as .suppress_bind_attrs = true, to make sure it can't be removed.

Quoted 22 lines · Thierry Reding

* PGP Signed by an unknown key

Quoted 9 lines · Jon Hunter

The genpd framework allows users to add power-domains via the pm_genpd_init() function, however, there is no corresponding function to remove a power-domain. For most devices this may be fine as the power domains are never removed, however, for devices that wish to populate the power-domains from within a driver, having the ability to remove a power domain if the probing of the device fails or the driver is unloaded is necessary. Therefore, add a function to remove a power-domain. Please note that the power domain can only be removed if there are no devices using the power-domain and it is not linked to another domain.

So I guess this introduces a problem not uncommon to other types of resources. If you remove the driver, even if you fail ->remove() the module may still go away along with any code associated with it. So even if the PM domains can't be removed, you can't prevent the module from going away. That could be somewhat mitigated if we were holding a module reference count, because then the only way to unload the driver would be via sysfs (we could prevent that too, which might be the best way to do this today).

Quoted 5 lines

There is work underway to solve this generically, Rafael was working on this, so I'm not sure we need to add additional infrastructure to the PM domain code as part of this series. But we may want to mark the Tegra PMC driver as .suppress_bind_attrs = true, to make sure it can't be removed.

I see what you are saying. It nearly seemed to me that I should use BUG_ON() if we fail to remove a genpd in the PMC driver, however, I know that using BUG_ON should be avoided. I will add the suppress_bind_attrs = true for the PMC driver as that does make sense for now.

The genpd framework allows users to add power-domains via the pm_genpd_init() function, however, there is no corresponding function to remove a power-domain. For most devices this may be fine as the power domains are never removed, however, for devices that wish to populate the power-domains from within a driver, having the ability to remove a power domain if the probing of the device fails or the driver is unloaded is necessary. Therefore, add a function to remove a power-domain. Please note that the power domain can only be removed if there are no devices using the power-domain and it is not linked to another domain.

Signed-off-by Jon Hunter <[email protected]>

---
 drivers/base/power/domain.c | 31 +++++++++++++++++++++++++++++++
 include/linux/pm_domain.h   |  5 +++++
 2 files changed, 36 insertions(+)

drivers/base/power/domain.c +11 -0

index 608bc00655ee..22f6e9d738bf 100644
@@ -1557,6 +1557,37 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
 }
 EXPORT_SYMBOL_GPL(pm_genpd_init);
 
+/**
+ * pm_genpd_remove - Remove a generic I/O PM domain object.
+ * @genpd: PM domain object to remove.
+ */
+int pm_genpd_remove(struct generic_pm_domain *genpd)
+{
+       int ret = 0;
+
+       if (IS_ERR_OR_NULL(genpd))
+               return -EINVAL;
+

drivers/base/power/domain.c +4 -0

+       return ret;
+}
+EXPORT_SYMBOL_GPL(pm_genpd_remove);
+
 #ifdef CONFIG_PM_GENERIC_DOMAINS_OF
 /*
  * Device Tree based PM domain providers.

include/linux/pm_domain.h +5 -1

index b38dd74dea9b..9ae9c42f807f 100644
@@ -134,6 +134,7 @@ extern int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
                                     struct generic_pm_domain *target);
 extern void pm_genpd_init(struct generic_pm_domain *genpd,
                          struct dev_power_governor *gov, bool is_off);
+extern int pm_genpd_remove(struct generic_pm_domain *genpd);
 
 extern struct dev_power_governor simple_qos_governor;
 extern struct dev_power_governor pm_domain_always_on_gov;

@@ -177,6 +178,10 @@ static inline void pm_genpd_init(struct generic_pm_domain *genpd,
                                 struct dev_power_governor *gov, bool is_off)
 {
 }
+static inline int pm_genpd_remove(struct generic_pm_domain *genpd)
+{
+       return -ENOTSUPP;
+}
 #endif
 
 static inline int pm_genpd_add_device(struct generic_pm_domain *genpd,
--

2.1.4

Add the PMC driver compatible strings for Tegra132 and Tegra210.

Signed-off-by Jon Hunter <[email protected]>

Acked-by Rob Herring <[email protected]>

---
 .../devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt     | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

Currently, the function tegra_powergate_set() simply sets the desired powergate state but does not wait for the state to change. In most cases we should wait for the state to change before proceeding. Currently, there is a case for tegra114 and tegra124 devices where we do not wait when starting the secondary CPU as this is not necessary. However, this is only done at boot time and so waiting here will only have a small impact on boot time. Therefore, update tegra_powergate_set() to wait when setting the powergate.

By adding this feature, we can also eliminate the polling loop from tegra30_boot_secondary().

A function has been added for checking the status of the powergate and so update the tegra_powergate_is_powered() to use this macro as well.

Signed-off-by Jon Hunter <[email protected]>

---
 arch/arm/mach-tegra/platsmp.c | 16 +++-------------
 drivers/soc/tegra/pmc.c       |  9 ++++++++-
 2 files changed, 11 insertions(+), 14 deletions(-)

* PGP Signed by an unknown key

Quoted 12 lines · Jon Hunter

Currently, the function tegra_powergate_set() simply sets the desired powergate state but does not wait for the state to change. In most cases we should wait for the state to change before proceeding. Currently, there is a case for tegra114 and tegra124 devices where we do not wait when starting the secondary CPU as this is not necessary. However, this is only done at boot time and so waiting here will only have a small impact on boot time. Therefore, update tegra_powergate_set() to wait when setting the powergate.

By adding this feature, we can also eliminate the polling loop from tegra30_boot_secondary().

Quoted 8 lines

A function has been added for checking the status of the powergate and so update the tegra_powergate_is_powered() to use this macro as well.

Signed-off-by Jon Hunter <[email protected]>

---
 arch/arm/mach-tegra/platsmp.c | 16 +++-------------
 drivers/soc/tegra/pmc.c       |  9 ++++++++-
 2 files changed, 11 insertions(+), 14 deletions(-)

This looks to be independent from the generic power domain support. Can I apply this separately (for 4.6, without waiting for the power domain series' dependencies to go in)?

Currently, the function tegra_powergate_set() simply sets the desired powergate state but does not wait for the state to change. In most cases we should wait for the state to change before proceeding. Currently, there is a case for tegra114 and tegra124 devices where we do not wait when starting the secondary CPU as this is not necessary. However, this is only done at boot time and so waiting here will only have a small impact on boot time. Therefore, update tegra_powergate_set() to wait when setting the powergate.

By adding this feature, we can also eliminate the polling loop from tegra30_boot_secondary().

A function has been added for checking the status of the powergate and so update the tegra_powergate_is_powered() to use this macro as well.

Signed-off-by Jon Hunter <[email protected]>

---
 arch/arm/mach-tegra/platsmp.c | 16 +++-------------
 drivers/soc/tegra/pmc.c       |  9 ++++++++-
 2 files changed, 11 insertions(+), 14 deletions(-)

Enable PM_GENERIC_DOMAINS for tegra 64-bit devices. To ensure that devices dependent upon a particular power-domain are only probed when that power domain has been powered up, requires that PM is made mandatory for tegra 64-bit devices and so select this option for tegra as well.

Signed-off-by Jon Hunter <[email protected]>

---
 arch/arm64/Kconfig.platforms | 2 ++
 1 file changed, 2 insertions(+)

arch/arm64/Kconfig.platforms +2 -1

index 1c3a137e216b..bd52c3e80ac5 100644
@@ -113,6 +113,8 @@ config ARCH_TEGRA
        select GENERIC_CLOCKEVENTS
        select HAVE_CLK
        select PINCTRL
+       select PM
+       select PM_GENERIC_DOMAINS
        select RESET_CONTROLLER
        help
          This enables support for the NVIDIA Tegra SoC family.
--

2.1.4

To remove generic PM domains in a sane way, we need to remove them by starting from the last PM domain added. The reason for this is that a PM domain may be a subdomain of another and so we need to remove the child PM domains for a given domain first. By removing PM domains in reverse order we can ensure that the children are removed first.

Add a new function to get the last PM domain that was added. In case PM domains are added by more than one device in the system (for example, on-chip domains and off-chip domains) add a 'owner' device structure to the generic PM domain structure so that the ownership of a PM domain can be identified by the device structure of the device that added it Use this 'owner' device structure to return the last PM domain added by this device.

Note that because pm_genpd_init() simply adds each PM domain to the head of the gpd_list object, list_for_each_entry() will start from the last PM domain added.

Signed-off-by Jon Hunter <[email protected]>

---
This is the outcome from a discussion I had with Ulf on how best to handle the removal of power-domains [0]. I opted to call the device structure 'owner' because 'parent' could be misleading if a power domain is a child of another power domain. However, open to suggestions!

[0] http://marc.info/?l=linux-pm&m=145460070816340&w=2

 drivers/base/power/domain.c | 25 +++++++++++++++++++++++++
 include/linux/pm_domain.h   |  7 +++++++
 2 files changed, 32 insertions(+)

To remove generic PM domains in a sane way, we need to remove them by starting from the last PM domain added. The reason for this is that a PM domain may be a subdomain of another and so we need to remove the child PM domains for a given domain first. By removing PM domains in reverse order we can ensure that the children are removed first.

Add a new function to get the last PM domain that was added. In case PM domains are added by more than one device in the system (for example, on-chip domains and off-chip domains) add a 'owner' device structure to the generic PM domain structure so that the ownership of a PM domain can be identified by the device structure of the device that added it Use this 'owner' device structure to return the last PM domain added by this device.

Note that because pm_genpd_init() simply adds each PM domain to the head of the gpd_list object, list_for_each_entry() will start from the last PM domain added.

Signed-off-by Jon Hunter <[email protected]>

---
This is the outcome from a discussion I had with Ulf on how best to handle the removal of power-domains [0]. I opted to call the device structure 'owner' because 'parent' could be misleading if a power domain is a child of another power domain. However, open to suggestions!

[0] http://marc.info/?l=linux-pm&m=145460070816340&w=2

 drivers/base/power/domain.c | 25 +++++++++++++++++++++++++
 include/linux/pm_domain.h   |  7 +++++++
 2 files changed, 32 insertions(+)

drivers/base/power/domain.c +25 -0

index ea9f2aa3fc33..608bc00655ee 100644
@@ -65,6 +65,31 @@ struct generic_pm_domain *pm_genpd_lookup_dev(struct device *dev)
 }
 
 /*
+ * Get the last generic PM domain added whose 'owner' device structure
+ * matches the device structure provided. The 'owner' device structure
+ * for a given PM domain should be initialised by the device that is
+ * creating the PM domains and hence, calling pm_genpd_init().
+ */
+struct generic_pm_domain *pm_genpd_list_get_tail(struct device *dev)
+{
+       struct generic_pm_domain *genpd = NULL, *gpd;
+
+       if (IS_ERR_OR_NULL(dev))
+               return NULL;
+
+       mutex_lock(&gpd_list_lock);
+       list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
+               if (gpd->owner == dev) {
+                       genpd = gpd;
+                       break;
+               }
+       }
+       mutex_unlock(&gpd_list_lock);
+
+       return genpd;
+}
+
+/*
  * This should only be used where we are certain that the pm_domain
  * attached to the device is a genpd domain.
  */

include/linux/pm_domain.h +7 -1

index 49cd8890b873..b38dd74dea9b 100644
@@ -46,6 +46,7 @@ struct genpd_power_state {
 
 struct generic_pm_domain {
        struct dev_pm_domain domain;    /* PM domain operations */
+       struct device *owner;           /* Identity of the domain owner */
        struct list_head gpd_list_node; /* Node in the global PM domains list */
        struct list_head master_links;  /* Links with PM domain as a master */
        struct list_head slave_links;   /* Links with PM domain as a slave */

@@ -120,6 +121,7 @@ static inline struct generic_pm_domain_data *dev_gpd_data(struct device *dev)
 }
 
 extern struct generic_pm_domain *pm_genpd_lookup_dev(struct device *dev);
+extern struct generic_pm_domain *pm_genpd_list_get_tail(struct device *dev);
 extern int __pm_genpd_add_device(struct generic_pm_domain *genpd,
                                 struct device *dev,
                                 struct gpd_timing_data *td);

@@ -145,6 +147,11 @@ static inline struct generic_pm_domain *pm_genpd_lookup_dev(struct device *dev)
 {
        return NULL;
 }
+static inline
+struct generic_pm_domain *pm_genpd_list_get_tail(struct device *dev)
+{
+       return NULL;
+}
 static inline int __pm_genpd_add_device(struct generic_pm_domain *genpd,
                                        struct device *dev,
                                        struct gpd_timing_data *td)
--

2.1.4

Add power-domain binding documentation for the NVIDIA PMC driver in order to support generic power-domains.

Signed-off-by Jon Hunter <[email protected]>

Acked-by Rob Herring <[email protected]>

---
 .../bindings/arm/tegra/nvidia,tegra20-pmc.txt      | 61 ++++++++++++++++++++++
 1 file changed, 61 insertions(+)

Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt +37 -0

index 53aa5496c5cf..0c383a9e720e 100644
@@ -1,5 +1,7 @@
 NVIDIA Tegra Power Management Controller (PMC)
 
+== Power Management Controller Node ==
+
 The PMC block interacts with an external Power Management Unit. The PMC
 mostly controls the entry and exit of the system from different sleep
 modes. It provides power-gating controllers for SoC and CPU power-islands.

@@ -70,6 +72,11 @@ Optional properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'
                      Defaults to 0. Valid values are described in section 12.5.2
                      "Pinmux Support" of the Tegra4 Technical Reference Manual.
 
+Optional nodes:
+- powergates : This node contains a hierarchy of power domain nodes, which
+	       should match the powergates on the Tegra SoC. See "Powergate
+	       Nodes" below.
+
 Example:
 
 / SoC dts including file

@@ -115,3 +122,57 @@ pmc@7000f400 {
 	};
...
 };
+
+
+== Powergate Nodes ==
+
+Each of the powergate nodes represents a power-domain on the Tegra SoC
+that can be power-gated by the PMC and should be named appropriately.
+
+Required properties:
+  - reg: Contains an integer value that identifies the PMC power-gate.
+    Please refer to the Tegra TRM for more details. The parent node
+    must contain the following two properties:
+    - #address-cells: Must be 1,
+    - #size-cells: Must be 0.
+  - clocks: Must contain an entry for each clock required by the PMC for
+    controlling a power-gate. See ../clocks/clock-bindings.txt for details.
+  - resets: Must contain an entry for each reset required by the PMC for
+    controlling a power-gate. See ../reset/reset.txt for details.
+  - #power-domain-cells: Must be 0.
+
+Example:
+
+	pmc: pmc@0,7000e400 {
+		compatible = "nvidia,tegra210-pmc";
+		reg = <0x0 0x7000e400 0x0 0x400>;
+		clocks = <&tegra_car TEGRA210_CLK_PCLK>, <&clk32k_in>;
+		clock-names = "pclk", "clk32k_in";
+
+		powergates {
+			#address-cells = <1>;
+			#size-cells = <0>;

* PGP Signed by an unknown key

Quoted 76 lines · Jon Hunter

Add power-domain binding documentation for the NVIDIA PMC driver in order to support generic power-domains.

Signed-off-by Jon Hunter <[email protected]>

Acked-by Rob Herring <[email protected]>

---
 .../bindings/arm/tegra/nvidia,tegra20-pmc.txt      | 61 ++++++++++++++++++++++
 1 file changed, 61 insertions(+)

Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt +46 -0

index 53aa5496c5cf..0c383a9e720e 100644
@@ -1,5 +1,7 @@
 NVIDIA Tegra Power Management Controller (PMC)
 
+== Power Management Controller Node ==
+
 The PMC block interacts with an external Power Management Unit. The PMC
 mostly controls the entry and exit of the system from different sleep
 modes. It provides power-gating controllers for SoC and CPU power-islands.

@@ -70,6 +72,11 @@ Optional properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'
                      Defaults to 0. Valid values are described in section 12.5.2
                      "Pinmux Support" of the Tegra4 Technical Reference Manual.
 
+Optional nodes:
+- powergates : This node contains a hierarchy of power domain nodes, which
+	       should match the powergates on the Tegra SoC. See "Powergate
+	       Nodes" below.
+
 Example:
 
 / SoC dts including file

@@ -115,3 +122,57 @@ pmc@7000f400 {
 	};
...
 };
+
+
+== Powergate Nodes ==
+
+Each of the powergate nodes represents a power-domain on the Tegra SoC
+that can be power-gated by the PMC and should be named appropriately.
+
+Required properties:
+  - reg: Contains an integer value that identifies the PMC power-gate.
+    Please refer to the Tegra TRM for more details. The parent node
+    must contain the following two properties:
+    - #address-cells: Must be 1,
+    - #size-cells: Must be 0.
+  - clocks: Must contain an entry for each clock required by the PMC for
+    controlling a power-gate. See ../clocks/clock-bindings.txt for details.
+  - resets: Must contain an entry for each reset required by the PMC for
+    controlling a power-gate. See ../reset/reset.txt for details.
+  - #power-domain-cells: Must be 0.
+
+Example:
+
+	pmc: pmc@0,7000e400 {
+		compatible = "nvidia,tegra210-pmc";
+		reg = <0x0 0x7000e400 0x0 0x400>;
+		clocks = <&tegra_car TEGRA210_CLK_PCLK>, <&clk32k_in>;
+		clock-names = "pclk", "clk32k_in";
+
+		powergates {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			pd_audio: aud {
+				reg = <TEGRA_POWERGATE_AUD>;
+				clocks = <&tegra_car TEGRA210_CLK_APE>,
+					 <&tegra_car TEGRA210_CLK_APB2APE>;
+				resets = <&tegra_car 198>;
+				#power-domain-cells = <0>;
+			};
+		};

Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt

Quoted 1 line

Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt +1 -0

+	};

Should we not spell out the list of supported power domains per SoC here? The example gives only one, but we have a bunch of others. If they can be referred to by phandle I'd expect there to be a list of them. I'm not sure if this was discussed earlier, but does it perhaps make sense to tie names to IDs, such that we don't need the reg property? That'd be analogous to how PMICs define regulators.

The reason why I'm asking is that in the above example it's possible to have this:

			pd_audio: pcie {
				reg = <TEGRA_POWERGATE_SOR>;
				...
			};

And there'd be no way to sanity check other than by human inspection. Perhaps I'm being overly paranoid and we can easily filter these out during code review.

Quoted 79 lines · Thierry Reding

* PGP Signed by an unknown key

Quoted 76 lines · Jon Hunter

Add power-domain binding documentation for the NVIDIA PMC driver in order to support generic power-domains.

Signed-off-by Jon Hunter <[email protected]>

Acked-by Rob Herring <[email protected]>

---
 .../bindings/arm/tegra/nvidia,tegra20-pmc.txt      | 61 ++++++++++++++++++++++
 1 file changed, 61 insertions(+)

Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt +46 -0

index 53aa5496c5cf..0c383a9e720e 100644
@@ -1,5 +1,7 @@
 NVIDIA Tegra Power Management Controller (PMC)
 
+== Power Management Controller Node ==
+
 The PMC block interacts with an external Power Management Unit. The PMC
 mostly controls the entry and exit of the system from different sleep
 modes. It provides power-gating controllers for SoC and CPU power-islands.

@@ -70,6 +72,11 @@ Optional properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'
                      Defaults to 0. Valid values are described in section 12.5.2
                      "Pinmux Support" of the Tegra4 Technical Reference Manual.
 
+Optional nodes:
+- powergates : This node contains a hierarchy of power domain nodes, which
+	       should match the powergates on the Tegra SoC. See "Powergate
+	       Nodes" below.
+
 Example:
 
 / SoC dts including file

@@ -115,3 +122,57 @@ pmc@7000f400 {
 	};
...
 };
+
+
+== Powergate Nodes ==
+
+Each of the powergate nodes represents a power-domain on the Tegra SoC
+that can be power-gated by the PMC and should be named appropriately.
+
+Required properties:
+  - reg: Contains an integer value that identifies the PMC power-gate.
+    Please refer to the Tegra TRM for more details. The parent node
+    must contain the following two properties:
+    - #address-cells: Must be 1,
+    - #size-cells: Must be 0.
+  - clocks: Must contain an entry for each clock required by the PMC for
+    controlling a power-gate. See ../clocks/clock-bindings.txt for details.
+  - resets: Must contain an entry for each reset required by the PMC for
+    controlling a power-gate. See ../reset/reset.txt for details.
+  - #power-domain-cells: Must be 0.
+
+Example:
+
+	pmc: pmc@0,7000e400 {
+		compatible = "nvidia,tegra210-pmc";
+		reg = <0x0 0x7000e400 0x0 0x400>;
+		clocks = <&tegra_car TEGRA210_CLK_PCLK>, <&clk32k_in>;
+		clock-names = "pclk", "clk32k_in";
+
+		powergates {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			pd_audio: aud {
+				reg = <TEGRA_POWERGATE_AUD>;
+				clocks = <&tegra_car TEGRA210_CLK_APE>,
+					 <&tegra_car TEGRA210_CLK_APB2APE>;
+				resets = <&tegra_car 198>;
+				#power-domain-cells = <0>;
+			};
+		};

Quoted 8 lines

Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt

Quoted 1 line

Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt +1 -0

+	};

Should we not spell out the list of supported power domains per SoC here? The example gives only one, but we have a bunch of others. If they can be referred to by phandle I'd expect there to be a list of them. I'm not sure if this was discussed earlier, but does it perhaps make sense to tie names to IDs, such that we don't need the reg property? That'd be analogous to how PMICs define regulators.

So the supported power-domains per SoC are described in the header "include/dt-bindings/power/tegra-powergate.h" (see patch #8). Perhaps, I can move patch #8 to before this patch and add a reference to the header file for a list of supported power-domains. However ...

Quoted 7 lines

The reason why I'm asking is that in the above example it's possible to have this:

			pd_audio: pcie {
				reg = <TEGRA_POWERGATE_SOR>;
				...
			};

... if we eliminate the "reg" property and just use the name, then yes it would make sense to move the list of support power-domains into the binding doc.

It all depends on whether we want to define the IDs in the binding or in the PMC driver. Right now we have a static list of power-domains in the PMC driver per SoC and I had thought that in the long term we would be able to get rid of these and just rely on the binding. But ...

Quoted 3 lines

And there'd be no way to sanity check other than by human inspection. Perhaps I'm being overly paranoid and we can easily filter these out during code review.

... that would mean that we have to rely on the binding being correct
and inspect manually. On the other hand, if we don't have the IDs in the binding we still need to inspect the static arrays in the PMC driver and so far I have found a few errors with these. So does it really change/improve anything?

I've always considered per-SoC invariant data to not belong into bindings. That is, constants such as power partition IDs or SMMU client IDs should be defined via tables in drivers, and DT should be used to hook them up to devices.

Defining the existing power domains in DT seems rather brittle to me. A compatible string would imply the set of supported power domains anyway and having that set specified in DT would technically require us to add code in the driver to validate that the DT is sane, which would entail the addition of a very similar table anyway.

One further reason why I prefer not to have these things specified (as opposed to "glued" together) in DT is that the DT is ABI, so if we ever happen to ship a broken DT we won't be able to easily fix it. Driver code, on the other hand, can always easily be fixed.

Adds generic PM support to the PMC driver where the PM domains are populated from device-tree and the PM domain consumer devices are bound to their relevant PM domains via device-tree as well.

Update the tegra_powergate_sequence_power_up() API so that internally it calls the same tegra_powergate_xxx functions that are used by the tegra generic power domain code for consistency.

To ensure that the Tegra power domains (a.k.a powergates) cannot be controlled via both the legacy tegra_powergate_xxx functions as well as the generic PM domain framework, add a bit map for available powergates that can be controlled via the legacy powergate functions.

Move the majority of the tegra_powergate_remove_clamping() function to a sub-function, so that this can be used by both the legacy and generic power domain code.

This is based upon work by Thierry Reding <[email protected]> and Vince Hsu <[email protected]>.

Signed-off-by Jon Hunter <[email protected]>

Add the audio power-domain for tegra210. Note that this also removes the existing "#power-domain-cells" which was incorrectly included by commit e53095857166 ("arm64: tegra: Add Tegra210 support").

Signed-off-by Jon Hunter <[email protected]>

---

So far I have only added the audio power-domain for tegra210 as this is what I have been testing with to date. However, once this series is accepted then we can begin to add more.

 arch/arm64/boot/dts/nvidia/tegra210.dtsi | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

* PGP Signed by an unknown key

Quoted 6 lines · Jon Hunter

Add the audio power-domain for tegra210. Note that this also removes the existing "#power-domain-cells" which was incorrectly included by commit e53095857166 ("arm64: tegra: Add Tegra210 support").

Signed-off-by Jon Hunter <[email protected]>

Quoted 8 lines

---

So far I have only added the audio power-domain for tegra210 as this is what I have been testing with to date. However, once this series is accepted then we can begin to add more.

 arch/arm64/boot/dts/nvidia/tegra210.dtsi | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

I'm slightly reluctant to apply this, since the domain isn't used anywhere. I'm assuming it will be used by the audio driver that you've been working on, but if that's not going to be merged this cycle, we'd end up with an unused label. Not that that's invalid in any way, but my rule of thumb has been not to introduce labels until they are used.

Therefore I suggest we postpone this to the series that adds audio support.

Quoted 24 lines · Thierry Reding

* PGP Signed by an unknown key

Quoted 6 lines · Jon Hunter

Add the audio power-domain for tegra210. Note that this also removes the existing "#power-domain-cells" which was incorrectly included by commit e53095857166 ("arm64: tegra: Add Tegra210 support").

Signed-off-by Jon Hunter <[email protected]>

Quoted 8 lines

---

So far I have only added the audio power-domain for tegra210 as this is what I have been testing with to date. However, once this series is accepted then we can begin to add more.

 arch/arm64/boot/dts/nvidia/tegra210.dtsi | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

I'm slightly reluctant to apply this, since the domain isn't used anywhere. I'm assuming it will be used by the audio driver that you've been working on, but if that's not going to be merged this cycle, we'd end up with an unused label. Not that that's invalid in any way, but my rule of thumb has been not to introduce labels until they are used.

Quoted 2 lines

Therefore I suggest we postpone this to the series that adds audio support.

That's fine with me or I can drop the label, until it is used by a device?

Adds generic PM domain support for Tegra SoCs but this series only enables support for it on Tegra 64-bit devices. There is no reason why this cannot be enable for Tegra 32-bit devices, but to keep the patch series to a minimum only 64-bit devices are enabled so far.

This series has been boot tested on Tegra210 as well as various 32-bit Tegra platforms.

Summary of changes since V5 [2]:
- Split series into 2 series, separating PMC fixes [3] from genpd changes
- This series is based upon fixes series (which is now in -next)
- Added patch to fix removal of genpd subdomain
- Added patch to get last genpd that was added
- Fixed locking in function to remove genpd
- Updated Tegra PMC driver to ensure power-domains cannot be controlled by both legacy Tegra APIs and generic PM domain framework
- Removed powergate list from Tegra PMC driver and updated removal of power domains to use new genpd APIs.

Summary of changes since V4 [1]:
- Re-worked fix to handle base address on probe failure
- Added patch to lock around simultaneuous accesses to PMC registers
- Added patch to change powergate and rail IDs to unsigned type
- Added patch to fix testing of powergate state
- Updated patch to check for valid powergates to use a bitmap
- Updated Tegra DT PMC bindings per Rob H's feedback
- Updated Tegra power domains binding per Thierry's feedback
- Updated Tegra generic power domain support per Thierry's feedback

Summary of changes since V3 [0]:
- Dropped tegra124 support for now
- Removed MC flush support per feedback from Thierry
- Cleaned up the PMC changes per feedback from Thierry
- Added support for tegra210

[0] http://comments.gmane.org/gmane.linux.ports.tegra/22944
[1] http://marc.info/?l=linux-tegra&m=144924153600529&w=2
[2] http://marc.info/?l=linux-tegra&m=145399885003830&w=2
[3] http://marc.info/?l=linux-tegra&m=145521381331144&w=2

Jon Hunter (10):
PM / Domains: Fix removal of a subdomain
PM / Domains: Add function to get the last domain added PM / Domains: Add function to remove a pm-domain

Quoted 7 lines · Jon Hunter

Adds generic PM domain support for Tegra SoCs but this series only enables support for it on Tegra 64-bit devices. There is no reason why this cannot be enable for Tegra 32-bit devices, but to keep the patch series to a minimum only 64-bit devices are enabled so far.

This series has been boot tested on Tegra210 as well as various 32-bit Tegra platforms.

Quoted 4 lines

Jon Hunter (10):
PM / Domains: Fix removal of a subdomain
PM / Domains: Add function to get the last domain added PM / Domains: Add function to remove a pm-domain

Ulf, Kevin, Rafael,

It's too late to take these patches through the Tegra tree for v4.6, but if Jon can get the above three patches ready before the merge window, would you be willing to pick them up into your trees for v4.6?

Doing so
might make it easier to deal with the dependencies. The prerequisites would already be in Linus' tree when I apply the Tegra bits for v4.7.

I don't mind taking all of it through the Tegra tree for v4.7, though. I can provide a stable branch with the PM / Domains patches for you to pull in, in case there are any conflicts.

Quoted 8 lines · Thierry Reding

Quoted 7 lines · Jon Hunter

Adds generic PM domain support for Tegra SoCs but this series only enables support for it on Tegra 64-bit devices. There is no reason why this cannot be enable for Tegra 32-bit devices, but to keep the patch series to a minimum only 64-bit devices are enabled so far.

This series has been boot tested on Tegra210 as well as various 32-bit Tegra platforms.

[...]

Quoted 10 lines

Quoted 4 lines

Jon Hunter (10):
PM / Domains: Fix removal of a subdomain
PM / Domains: Add function to get the last domain added PM / Domains: Add function to remove a pm-domain

Ulf, Kevin, Rafael,

It's too late to take these patches through the Tegra tree for v4.6, but if Jon can get the above three patches ready before the merge window, would you be willing to pick them up into your trees for v4.6?

It's a bit late in the cycle, but since one is a fix and the other two add functions that aren't (yet) used, I think it would be fine to get them in for v4.6. But, the final decision is with Rafael.

Quoted 3 lines

Doing so
might make it easier to deal with the dependencies. The prerequisites would already be in Linus' tree when I apply the Tegra bits for v4.7.

Yeah, makes sense.

Quoted 3 lines

I don't mind taking all of it through the Tegra tree for v4.7, though. I can provide a stable branch with the PM / Domains patches for you to pull in, in case there are any conflicts.

I think it makes the most sense for these prereqs to merge through linux-pm. Let's see what Rafael thinks about the timing.

Quoted 38 lines · Kevin Hilman

Quoted 8 lines · Thierry Reding

Quoted 7 lines · Jon Hunter

Adds generic PM domain support for Tegra SoCs but this series only enables support for it on Tegra 64-bit devices. There is no reason why this cannot be enable for Tegra 32-bit devices, but to keep the patch series to a minimum only 64-bit devices are enabled so far.

This series has been boot tested on Tegra210 as well as various 32-bit Tegra platforms.

[...]

Quoted 10 lines

Quoted 4 lines

Jon Hunter (10):
PM / Domains: Fix removal of a subdomain
PM / Domains: Add function to get the last domain added PM / Domains: Add function to remove a pm-domain

Ulf, Kevin, Rafael,

It's too late to take these patches through the Tegra tree for v4.6, but if Jon can get the above three patches ready before the merge window, would you be willing to pick them up into your trees for v4.6?

It's a bit late in the cycle, but since one is a fix and the other two add functions that aren't (yet) used, I think it would be fine to get them in for v4.6. But, the final decision is with Rafael.

Quoted 3 lines

Doing so
might make it easier to deal with the dependencies. The prerequisites would already be in Linus' tree when I apply the Tegra bits for v4.7.

Yeah, makes sense.

Quoted 3 lines

I don't mind taking all of it through the Tegra tree for v4.7, though. I can provide a stable branch with the PM / Domains patches for you to pull in, in case there are any conflicts.

Quoted 2 lines

I think it makes the most sense for these prereqs to merge through linux-pm. Let's see what Rafael thinks about the timing.

The timing is fine by me.

Do you want me to apply [1-3/10] from this series, then?

Quoted 39 lines · Rafael J. Wysocki

Quoted 38 lines · Kevin Hilman

Quoted 8 lines · Thierry Reding

Quoted 7 lines · Jon Hunter

Adds generic PM domain support for Tegra SoCs but this series only enables support for it on Tegra 64-bit devices. There is no reason why this cannot be enable for Tegra 32-bit devices, but to keep the patch series to a minimum only 64-bit devices are enabled so far.

This series has been boot tested on Tegra210 as well as various 32-bit Tegra platforms.

[...]

Quoted 10 lines

Quoted 4 lines

Jon Hunter (10):
PM / Domains: Fix removal of a subdomain
PM / Domains: Add function to get the last domain added PM / Domains: Add function to remove a pm-domain

Ulf, Kevin, Rafael,

It's too late to take these patches through the Tegra tree for v4.6, but if Jon can get the above three patches ready before the merge window, would you be willing to pick them up into your trees for v4.6?

It's a bit late in the cycle, but since one is a fix and the other two add functions that aren't (yet) used, I think it would be fine to get them in for v4.6. But, the final decision is with Rafael.

Quoted 3 lines

Doing so
might make it easier to deal with the dependencies. The prerequisites would already be in Linus' tree when I apply the Tegra bits for v4.7.

Yeah, makes sense.

Quoted 3 lines

I don't mind taking all of it through the Tegra tree for v4.7, though. I can provide a stable branch with the PM / Domains patches for you to pull in, in case there are any conflicts.

Quoted 6 lines

Quoted 2 lines

I think it makes the most sense for these prereqs to merge through linux-pm. Let's see what Rafael thinks about the timing.

The timing is fine by me.

Do you want me to apply [1-3/10] from this series, then?

Jon has some minor tweaks to do, so he'll respin and then you can take them.

Jon, feel free to add:

Acked-by Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/[email protected]>

For those as well. I thought I responded, but looks like I didn't.

Quoted 53 lines · Kevin Hilman

Quoted 39 lines · Rafael J. Wysocki

Quoted 38 lines · Kevin Hilman

Quoted 8 lines · Thierry Reding

Quoted 7 lines · Jon Hunter

Adds generic PM domain support for Tegra SoCs but this series only enables support for it on Tegra 64-bit devices. There is no reason why this cannot be enable for Tegra 32-bit devices, but to keep the patch series to a minimum only 64-bit devices are enabled so far.

This series has been boot tested on Tegra210 as well as various 32-bit Tegra platforms.

[...]

Quoted 10 lines

Quoted 4 lines

Jon Hunter (10):
PM / Domains: Fix removal of a subdomain
PM / Domains: Add function to get the last domain added PM / Domains: Add function to remove a pm-domain

Ulf, Kevin, Rafael,

It's too late to take these patches through the Tegra tree for v4.6, but if Jon can get the above three patches ready before the merge window, would you be willing to pick them up into your trees for v4.6?

It's a bit late in the cycle, but since one is a fix and the other two add functions that aren't (yet) used, I think it would be fine to get them in for v4.6. But, the final decision is with Rafael.

Quoted 3 lines

Doing so
might make it easier to deal with the dependencies. The prerequisites would already be in Linus' tree when I apply the Tegra bits for v4.7.

Yeah, makes sense.

Quoted 3 lines

I don't mind taking all of it through the Tegra tree for v4.7, though. I can provide a stable branch with the PM / Domains patches for you to pull in, in case there are any conflicts.

Quoted 6 lines

Quoted 2 lines

I think it makes the most sense for these prereqs to merge through linux-pm. Let's see what Rafael thinks about the timing.

The timing is fine by me.

Do you want me to apply [1-3/10] from this series, then?

Jon has some minor tweaks to do, so he'll respin and then you can take them.

Jon, feel free to add:

Quoted 3 lines

Acked-by Kevin Hilman <[email protected]>

For those as well. I thought I responded, but looks like I didn't.

I am preparing a V7 that I will send out today/tomorrow (latest). I am going to drop the removal parts for now and send that out separately as an RFC because it is bigger than I have expected.