PM / Domains: DT support for domain idle states & atomic PM domains

This patch allows domains to define idle states in the DT. SoC's can define domain idle states in DT using the "domain-idle-states" property of the domain provider. Add API to read the idle states from DT that can be set in the genpd object.

This patch is based on the original patch by Marc Titinger.

Signed-off-by Marc Titinger <[email protected]>

Signed-off-by Ulf Hansson <[email protected]>

Signed-off-by Lina Iyer <[email protected]>

---
 drivers/base/power/domain.c | 94 +++++++++++++++++++++++++++++++++++++++++++++
 include/linux/pm_domain.h   |  8 ++++
 2 files changed, 102 insertions(+)

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

index 37ab7f1..9af75ba 100644

Quoted 20 lines · Lina Iyer

This patch allows domains to define idle states in the DT. SoC's can define domain idle states in DT using the "domain-idle-states" property of the domain provider. Add API to read the idle states from DT that can be set in the genpd object.

This patch is based on the original patch by Marc Titinger.

Signed-off-by Marc Titinger <[email protected]>

Signed-off-by Ulf Hansson <[email protected]>

Signed-off-by Lina Iyer <[email protected]>

---
drivers/base/power/domain.c | 94 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/pm_domain.h | 8 ++++

2 files changed, 102 insertions(+)

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

index 37ab7f1..9af75ba 100644

drivers/base/power/domain.c out: · line 1924

Quoted 9 lines

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

@@ -1916,6 +1916,100 @@ out:
 	return ret ? -EPROBE_DEFER : 0;
 }
 EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
+
+static const struct of_device_id idle_state_match[] = {
+	{ .compatible = "arm,idle-state", },
+	{ }
+};
+

I still think it's better to have another compatible to serve this purpose. We don't want to end up creating genpd domains just because they are "arm,idle-state" compatible IMO ?

I agree you can prevent it checking for OSC mode support in the firmware. But I want to understand if you have any strong reasons for avoiding that approach.

Hi Sudeep,

Quoted 38 lines · Sudeep Holla

Quoted 21 lines · Lina Iyer

This patch allows domains to define idle states in the DT. SoC's can define domain idle states in DT using the "domain-idle-states" property of the domain provider. Add API to read the idle states from DT that can be set in the genpd object.

This patch is based on the original patch by Marc Titinger.

Signed-off-by Marc Titinger <[email protected]>

Signed-off-by Ulf Hansson <[email protected]>

Signed-off-by Lina Iyer <[email protected]>

---
drivers/base/power/domain.c | 94
+++++++++++++++++++++++++++++++++++++++++++++
include/linux/pm_domain.h | 8 ++++

2 files changed, 102 insertions(+)

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

index 37ab7f1..9af75ba 100644

drivers/base/power/domain.c out: · line 1924

Quoted 9 lines

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

@@ -1916,6 +1916,100 @@ out:
    return ret ? -EPROBE_DEFER : 0;
 }
 EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
+
+static const struct of_device_id idle_state_match[] = {
+    { .compatible = "arm,idle-state", },
+    { }
+};
+

I still think it's better to have another compatible to serve this purpose. We don't want to end up creating genpd domains just because they are "arm,idle-state" compatible IMO ?

Quoted 4 lines

I agree you can prevent it checking for OSC mode support in the firmware. But I want to understand if you have any strong reasons for avoiding that approach.

Why are you still held up with OSI/PC PSCI modes?

I repeat again this
series is not about any of that, it is just about PM domains.

PM domains
have idle states and the idle-state description is similar in definition to arm,idle-state and therefore uses the same compatible. There is no point re-defining something that already exists in the kernel.

I was able to find the original thread, where we discussed this [1].

I suggest, you read about PM domains and its idle states and understand this series in the context of PM domains.

Quoted 41 lines · Lina Iyer

Hi Sudeep,

Quoted 38 lines · Sudeep Holla

Quoted 21 lines · Lina Iyer

This patch allows domains to define idle states in the DT. SoC's can define domain idle states in DT using the "domain-idle-states" property of the domain provider. Add API to read the idle states from DT that can be set in the genpd object.

This patch is based on the original patch by Marc Titinger.

Signed-off-by Marc Titinger <[email protected]>

Signed-off-by Ulf Hansson <[email protected]>

Signed-off-by Lina Iyer <[email protected]>

---
drivers/base/power/domain.c | 94
+++++++++++++++++++++++++++++++++++++++++++++
include/linux/pm_domain.h | 8 ++++

2 files changed, 102 insertions(+)

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

index 37ab7f1..9af75ba 100644

drivers/base/power/domain.c out: · line 1924

Quoted 9 lines

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

@@ -1916,6 +1916,100 @@ out:
   return ret ? -EPROBE_DEFER : 0;
 }
 EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
+
+static const struct of_device_id idle_state_match[] = {
+    { .compatible = "arm,idle-state", },
+    { }
+};
+

I still think it's better to have another compatible to serve this purpose. We don't want to end up creating genpd domains just because they are "arm,idle-state" compatible IMO ?

Quoted 5 lines

Quoted 4 lines

I agree you can prevent it checking for OSC mode support in the firmware. But I want to understand if you have any strong reasons for avoiding that approach.

Why are you still held up with OSI/PC PSCI modes?

I am just pointing that out to make sure you are not defining these DT bindings with just QCOM platform and OSC in consideration.

I am thinking about how can it be used/extended in other use-cases.

Quoted 2 lines

I repeat again this
series is not about any of that, it is just about PM domains.

I completely understand that, no argument on that. What I worry is that if a system(in future) represents this power domains and domain idles states and doesn't want to create a genpd, do we have to handle it differently or even the way your CPUidle series would do or can we say those states need to specify that they are compatible with the new feature(the one being added in this series) with a new compatible. I prefer the latter than the former to avoid all possible workarounds in future.

Quoted 5 lines

PM domains
have idle states and the idle-state description is similar in definition to arm,idle-state and therefore uses the same compatible. There is no point re-defining something that already exists in the kernel.

Yes I understand that but "arm,idle-states" were not defined with this feature in mind and hence I am bit worried if it could cause any issue especially if deprecate cpu-idle-states and move to this model completely. I really don't like this mix and hence I am raising the concern here. I am trying to ease that migration.

Quoted 5 lines

I was able to find the original thread, where we discussed this [1].

I suggest, you read about PM domains and its idle states and understand this series in the context of PM domains.

Sure, will do that. Thanks for pointing that out. But the concern I am raising is entirely different. I am asking if this re-use will cause any issue in future as pointed out above.

I re-iterate that I understand this series is independent of the CPUIdle and hence asking why not make it completely independent by just adding the new compatible.

I am *not asking to redefine something completely*. What I am saying is *just* to add new compatible that may(for cpu devices)/may not(for other/non-CPU devices) be used along with "arm,idle-state".

I may be too paranoid here but I think that's safer. It helps to skip creating of genpd if required for some domains as I had explained before.

Signature · 2 lines

Regards,
Sudeep

Hi Sudeep,

I was able to find the original thread, where we discussed this [1].

[1]. http://www.serverphorums.com/read.php?12,1303996

Update documentation to reflect the changes made to support IRQ safe PM domains.

Signed-off-by Lina Iyer <[email protected]>

Acked-by Ulf Hansson <[email protected]>

---
 Documentation/power/devices.txt | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

Documentation/power/devices.txt +0 -0

index 8ba6625..0401b53 100644
@@ -607,7 +607,14 @@ individually.  Instead, a set of devices sharing a power resource can be put
 into a low-power state together at the same time by turning off the shared
 power resource.  Of course, they also need to be put into the full-power state

Quoted 20 lines · Lina Iyer

Update documentation to reflect the changes made to support IRQ safe PM domains.

Signed-off-by Lina Iyer <[email protected]>

Acked-by Ulf Hansson <[email protected]>

---
 Documentation/power/devices.txt | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

Documentation/power/devices.txt +2 -1

index 8ba6625..0401b53 100644
@@ -607,7 +607,14 @@ individually.  Instead, a set of devices sharing a power resource can be put
 into a low-power state together at the same time by turning off the shared
 power resource.  Of course, they also need to be put into the full-power state
 together, by turning the shared power resource on.  A set of devices with this
-property is often referred to as a power domain.
+property is often referred to as a power domain. A power domain may also be
+nested inside another power domain.

Documentation/power/devices.txt individually. Instead, a set of devices sharing a power resource can be put · line 617

Quoted 6 lines

Documentation/power/devices.txt +6 -0

+
+Devices and PM domains may be defined as IRQ-safe, if they can be powered
+on/off even when the IRQs are disabled. An IRQ-safe device in a domain will
+disallow power management on the domain, unless the domain is also defined as
+IRQ-safe. The restriction this framework imposes on the parent domain of an
+IRQ-safe domain is that it must also be defined as IRQ-safe.

I would put this paragraph below, before the last paragraph in the section.

Also I suppose that a domain should only be defined as "IRQ-safe" if all of the devices in it are "IRQ-safe" (or there will be problems at least in principle). If that is the case, it should be stated clearly in the paragraph you are adding as well.

Update documentation to reflect the changes made to support IRQ safe PM domains.

Signed-off-by Lina Iyer <[email protected]>

Acked-by Ulf Hansson <[email protected]>

---
Changes since v3:
- Moved para to the end of the section
- Added clause for all IRQ safe devices in a domain
- Cleanup explanation of nested domains

---
 Documentation/power/devices.txt | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

Documentation/power/devices.txt +3 -1

index 8ba6625..9218ce6 100644
@@ -607,7 +607,9 @@ individually.  Instead, a set of devices sharing a power resource can be put
 into a low-power state together at the same time by turning off the shared
 power resource.  Of course, they also need to be put into the full-power state
 together, by turning the shared power resource on.  A set of devices with this
-property is often referred to as a power domain.
+property is often referred to as a power domain. A power domain may also be
+nested inside another power domain. The nested domain is referred to as the
+sub-domain of the parent domain.
 
 Support for power domains is provided through the pm_domain field of struct
 device.  This field is a pointer to an object of type struct dev_pm_domain,

Quoted 30 lines · Lina Iyer

Update documentation to reflect the changes made to support IRQ safe PM domains.

Signed-off-by Lina Iyer <[email protected]>

Acked-by Ulf Hansson <[email protected]>

---
Changes since v3:
- Moved para to the end of the section
- Added clause for all IRQ safe devices in a domain
- Cleanup explanation of nested domains

---
 Documentation/power/devices.txt | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

Documentation/power/devices.txt +3 -1

index 8ba6625..9218ce6 100644
@@ -607,7 +607,9 @@ individually.  Instead, a set of devices sharing a power resource can be put
 into a low-power state together at the same time by turning off the shared
 power resource.  Of course, they also need to be put into the full-power state
 together, by turning the shared power resource on.  A set of devices with this
-property is often referred to as a power domain.
+property is often referred to as a power domain. A power domain may also be
+nested inside another power domain. The nested domain is referred to as the
+sub-domain of the parent domain.
 
 Support for power domains is provided through the pm_domain field of struct
 device.  This field is a pointer to an object of type struct dev_pm_domain,

Documentation/power/devices.txt support for power domains into subsystem-level callbacks, for example by · line 635

Quoted 5 lines

Documentation/power/devices.txt +2 -0

@@ -629,6 +631,13 @@ support for power domains into subsystem-level callbacks, for example by
 modifying the platform bus type.  Other platforms need not implement it or take
 it into account in any way.
 
+Devices and PM domains may be defined as IRQ-safe, if they can be powered
+on/off even when the IRQs are disabled.

What IRQ-safe means for devices is that their runtime PM callbacks may be invoked with interrupts disabled on the local CPU. I guess the meaning of IRQ-safe for PM domains is analogous, but the above isn't precise enough to me.

Documentation/power/devices.txt support for power domains into subsystem-level callbacks, for example by · line 640

Quoted 6 lines

An IRQ-safe device in a domain will

Documentation/power/devices.txt +5 -0

+disallow power management on the domain, unless the domain is also defined as
+IRQ-safe. In other words, a domain containing all IRQ-safe devices must also
+be defined as IRQ-safe. Another restriction this framework imposes on the
+parent domain of an IRQ-safe domain is that the parent domain must also be
+defined as IRQ-safe.

What about this:

"Devices may be defined as IRQ-safe which indicates to the PM core that their runtime PM callbacks may be invoked with disabled interrupts (see Documentation/power/runtime_pm.txt for more information). If an IRQ-safe device belongs to a PM domain, the runtime PM of the domain will be disallowed, unless the domain itself is defined as IRQ-safe. However, a PM domain can only be defined as IRQ-safe if all of the devices in it are IRQ-safe.

Moreover, if
an IRQ-safe domain has a parent domain, the runtime PM of the parent is only allowed if the parent itself is IRQ-safe too with the additional restriction that all child domains of an IRQ-safe parent must also be IRQ-safe."

Does it actually reflect what the code does?

Quoted 50 lines · Rafael J. Wysocki

Quoted 30 lines · Lina Iyer

Update documentation to reflect the changes made to support IRQ safe PM domains.

Signed-off-by Lina Iyer <[email protected]>

Acked-by Ulf Hansson <[email protected]>

---
Changes since v3:
- Moved para to the end of the section
- Added clause for all IRQ safe devices in a domain
- Cleanup explanation of nested domains

---
 Documentation/power/devices.txt | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

Documentation/power/devices.txt +3 -1

index 8ba6625..9218ce6 100644
@@ -607,7 +607,9 @@ individually.  Instead, a set of devices sharing a power resource can be put
 into a low-power state together at the same time by turning off the shared
 power resource.  Of course, they also need to be put into the full-power state
 together, by turning the shared power resource on.  A set of devices with this
-property is often referred to as a power domain.
+property is often referred to as a power domain. A power domain may also be
+nested inside another power domain. The nested domain is referred to as the
+sub-domain of the parent domain.
 
 Support for power domains is provided through the pm_domain field of struct
 device.  This field is a pointer to an object of type struct dev_pm_domain,

Documentation/power/devices.txt support for power domains into subsystem-level callbacks, for example by · line 635

Quoted 5 lines

Documentation/power/devices.txt +2 -0

@@ -629,6 +631,13 @@ support for power domains into subsystem-level callbacks, for example by
 modifying the platform bus type.  Other platforms need not implement it or take
 it into account in any way.
 
+Devices and PM domains may be defined as IRQ-safe, if they can be powered
+on/off even when the IRQs are disabled.

What IRQ-safe means for devices is that their runtime PM callbacks may be invoked with interrupts disabled on the local CPU. I guess the meaning of IRQ-safe for PM domains is analogous, but the above isn't precise enough to me.

Documentation/power/devices.txt support for power domains into subsystem-level callbacks, for example by · line 640

Quoted 6 lines

An IRQ-safe device in a domain will

Documentation/power/devices.txt +5 -0

+disallow power management on the domain, unless the domain is also defined as
+IRQ-safe. In other words, a domain containing all IRQ-safe devices must also
+be defined as IRQ-safe. Another restriction this framework imposes on the
+parent domain of an IRQ-safe domain is that the parent domain must also be
+defined as IRQ-safe.

What about this:

Quoted 7 lines

"Devices may be defined as IRQ-safe which indicates to the PM core that their runtime PM callbacks may be invoked with disabled interrupts (see Documentation/power/runtime_pm.txt for more information). If an IRQ-safe device belongs to a PM domain, the runtime PM of the domain will be disallowed, unless the domain itself is defined as IRQ-safe. However, a PM domain can only be defined as IRQ-safe if all of the devices in it are IRQ-safe.

This is correct. But the last line may need a bit of modification. If all devices in a PM domain are IRQ-safe and the domain is NOT, then it it is a valid combination just that the domain would never do runtime PM.

Quoted 58 lines · Lina Iyer

Quoted 50 lines · Rafael J. Wysocki

Quoted 30 lines · Lina Iyer

Update documentation to reflect the changes made to support IRQ safe PM domains.

Signed-off-by Lina Iyer <[email protected]>

Acked-by Ulf Hansson <[email protected]>

---
Changes since v3:
- Moved para to the end of the section
- Added clause for all IRQ safe devices in a domain
- Cleanup explanation of nested domains

---
 Documentation/power/devices.txt | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

Documentation/power/devices.txt +3 -1

index 8ba6625..9218ce6 100644
@@ -607,7 +607,9 @@ individually.  Instead, a set of devices sharing a power resource can be put
 into a low-power state together at the same time by turning off the shared
 power resource.  Of course, they also need to be put into the full-power state
 together, by turning the shared power resource on.  A set of devices with this
-property is often referred to as a power domain.
+property is often referred to as a power domain. A power domain may also be
+nested inside another power domain. The nested domain is referred to as the
+sub-domain of the parent domain.
 
 Support for power domains is provided through the pm_domain field of struct
 device.  This field is a pointer to an object of type struct dev_pm_domain,

Documentation/power/devices.txt support for power domains into subsystem-level callbacks, for example by · line 635

Quoted 5 lines

Documentation/power/devices.txt +2 -0

@@ -629,6 +631,13 @@ support for power domains into subsystem-level callbacks, for example by
 modifying the platform bus type.  Other platforms need not implement it or take
 it into account in any way.
 
+Devices and PM domains may be defined as IRQ-safe, if they can be powered
+on/off even when the IRQs are disabled.

What IRQ-safe means for devices is that their runtime PM callbacks may be invoked with interrupts disabled on the local CPU. I guess the meaning of IRQ-safe for PM domains is analogous, but the above isn't precise enough to me.

Documentation/power/devices.txt support for power domains into subsystem-level callbacks, for example by · line 640

Quoted 6 lines

An IRQ-safe device in a domain will

Documentation/power/devices.txt +5 -0

+disallow power management on the domain, unless the domain is also defined as
+IRQ-safe. In other words, a domain containing all IRQ-safe devices must also
+be defined as IRQ-safe. Another restriction this framework imposes on the
+parent domain of an IRQ-safe domain is that the parent domain must also be
+defined as IRQ-safe.

What about this:

Quoted 7 lines

"Devices may be defined as IRQ-safe which indicates to the PM core that their runtime PM callbacks may be invoked with disabled interrupts (see Documentation/power/runtime_pm.txt for more information). If an IRQ-safe device belongs to a PM domain, the runtime PM of the domain will be disallowed, unless the domain itself is defined as IRQ-safe. However, a PM domain can only be defined as IRQ-safe if all of the devices in it are IRQ-safe.

Quoted 4 lines

This is correct. But the last line may need a bit of modification. If all devices in a PM domain are IRQ-safe and the domain is NOT, then it it is a valid combination just that the domain would never do runtime PM.

That doesn't contradict the last sentence of mine above. I guess what you mean is that having a non-IRQ-safe device in an IRQ-safe domain is a valid configuration. I wonder how it works then. :-)

In any case, what about changing that sentence to something like:

"However, it only makes sense to define a PM domain as IRQ-safe if all devices in it are IRQ-safe."

Hi all,

Changes since v2 [3] -
- Addressed review comments from v2.
- domain-idle-states documentation updated
- fixed compiler issues with imx driver
- minor code change in pm_domains.c
- The series is available at [4].

Changes since v1 [2] -
- Addressed review comments from v1.
- Fixes around dynamic allocation of genpd states
- Used OF method for iterating phandles
- Updated documentation, examples
- Rename state variable (provider -> fwnode)
- The series is available at [3].

The changes from [1] are -
- Allocating memory for domain idle states dynamically
- Conform to naming conventions for internal and exported genpd functions
- DT binding example for domain-idle-state
- Use fwnode instead of of_node
- Handle atomic case for removal of PM Domain
- Rebase on top of Rafael's pm/genpd tree

Thanks,
Lina

Lina Iyer (8):
PM / Domains: Make genpd state allocation dynamic
PM / Domain: Add residency property to genpd states PM / Domains: Allow domain power states to be read from DT PM / Domains: Save the fwnode in genpd_power_state dt/bindings: Update binding for PM domain idle states PM / Domains: Abstract genpd locking
PM / Domains: Support IRQ safe PM domains
PM / doc: Update device documentation for devices in IRQ safe PM
domains

 .../devicetree/bindings/power/power_domain.txt     |  43 +++
 Documentation/power/devices.txt                    |   9 +-
 arch/arm/mach-imx/gpc.c                            |  17 +-
 drivers/base/power/domain.c                        | 358 +++++++++++++++++----
 include/linux/pm_domain.h                          |  28 +-
 5 files changed, 383 insertions(+), 72 deletions(-)

--
2.7.4

[1]. https://www.spinics.net/lists/arm-kernel/msg526814.html
[2]. http://www.spinics.net/lists/arm-kernel/msg535106.html
[3]. https://git.linaro.org/people/lina.iyer/linux-next.git/shortlog/refs/heads/genpd-v2
[4]. https://git.linaro.org/people/lina.iyer/linux-next.git/shortlog/refs/heads/genpd-v3

Quoted 39 lines · Lina Iyer

Hi all,

Changes since v2 [3] -
- Addressed review comments from v2.
- domain-idle-states documentation updated
- fixed compiler issues with imx driver
- minor code change in pm_domains.c
- The series is available at [4].

Changes since v1 [2] -
- Addressed review comments from v1.
- Fixes around dynamic allocation of genpd states
- Used OF method for iterating phandles
- Updated documentation, examples
- Rename state variable (provider -> fwnode)
- The series is available at [3].

The changes from [1] are -
- Allocating memory for domain idle states dynamically
- Conform to naming conventions for internal and exported genpd functions
- DT binding example for domain-idle-state
- Use fwnode instead of of_node
- Handle atomic case for removal of PM Domain
- Rebase on top of Rafael's pm/genpd tree

Thanks,
Lina

Lina Iyer (8):
PM / Domains: Make genpd state allocation dynamic
PM / Domain: Add residency property to genpd states PM / Domains: Allow domain power states to be read from DT PM / Domains: Save the fwnode in genpd_power_state dt/bindings: Update binding for PM domain idle states PM / Domains: Abstract genpd locking
PM / Domains: Support IRQ safe PM domains
PM / doc: Update device documentation for devices in IRQ safe PM
domains

Quoted 7 lines

 .../devicetree/bindings/power/power_domain.txt     |  43 +++
 Documentation/power/devices.txt                    |   9 +-
 arch/arm/mach-imx/gpc.c                            |  17 +-
 drivers/base/power/domain.c                        | 358 +++++++++++++++++----
 include/linux/pm_domain.h                          |  28 +-
 5 files changed, 383 insertions(+), 72 deletions(-)

Rafael, Lina,

This looks good to me! Unless any other objections, I suggest to apply this to get it tested in linux-next.

Kind regards
Uffe

Quoted 7 lines

--
2.7.4

[1]. https://www.spinics.net/lists/arm-kernel/msg526814.html
[2]. http://www.spinics.net/lists/arm-kernel/msg535106.html
[3]. https://git.linaro.org/people/lina.iyer/linux-next.git/shortlog/refs/heads/genpd-v2
[4]. https://git.linaro.org/people/lina.iyer/linux-next.git/shortlog/refs/heads/genpd-v3

Quoted 56 lines · Ulf Hansson

Quoted 40 lines · Lina Iyer

Hi all,

Changes since v2 [3] -
- Addressed review comments from v2.
- domain-idle-states documentation updated
- fixed compiler issues with imx driver
- minor code change in pm_domains.c
- The series is available at [4].

Changes since v1 [2] -
- Addressed review comments from v1.
- Fixes around dynamic allocation of genpd states
- Used OF method for iterating phandles
- Updated documentation, examples
- Rename state variable (provider -> fwnode)
- The series is available at [3].

The changes from [1] are -
- Allocating memory for domain idle states dynamically
- Conform to naming conventions for internal and exported genpd functions
- DT binding example for domain-idle-state
- Use fwnode instead of of_node
- Handle atomic case for removal of PM Domain
- Rebase on top of Rafael's pm/genpd tree

Thanks,
Lina

Lina Iyer (8):
PM / Domains: Make genpd state allocation dynamic
PM / Domain: Add residency property to genpd states PM / Domains: Allow domain power states to be read from DT PM / Domains: Save the fwnode in genpd_power_state dt/bindings: Update binding for PM domain idle states PM / Domains: Abstract genpd locking
PM / Domains: Support IRQ safe PM domains
PM / doc: Update device documentation for devices in IRQ safe PM
domains

Quoted 8 lines

 .../devicetree/bindings/power/power_domain.txt     |  43 +++
 Documentation/power/devices.txt                    |   9 +-
 arch/arm/mach-imx/gpc.c                            |  17 +-
 drivers/base/power/domain.c                        | 358
+++++++++++++++++----
 include/linux/pm_domain.h                          |  28 +-
 5 files changed, 383 insertions(+), 72 deletions(-)

Rafael, Lina,

This looks good to me! Unless any other objections, I suggest to apply this to get it tested in linux-next.

Quoted 3 lines

Kind regards
Uffe

Rafael,

If there are no objections, could you pick this patch for linux-next?

Quoted 57 lines · Lina Iyer

Quoted 56 lines · Ulf Hansson

Quoted 40 lines · Lina Iyer

Hi all,

Changes since v2 [3] -
- Addressed review comments from v2.
- domain-idle-states documentation updated
- fixed compiler issues with imx driver
- minor code change in pm_domains.c
- The series is available at [4].

Changes since v1 [2] -
- Addressed review comments from v1.
- Fixes around dynamic allocation of genpd states
- Used OF method for iterating phandles
- Updated documentation, examples
- Rename state variable (provider -> fwnode)
- The series is available at [3].

The changes from [1] are -
- Allocating memory for domain idle states dynamically
- Conform to naming conventions for internal and exported genpd functions
- DT binding example for domain-idle-state
- Use fwnode instead of of_node
- Handle atomic case for removal of PM Domain
- Rebase on top of Rafael's pm/genpd tree

Thanks,
Lina

Lina Iyer (8):
PM / Domains: Make genpd state allocation dynamic
PM / Domain: Add residency property to genpd states PM / Domains: Allow domain power states to be read from DT PM / Domains: Save the fwnode in genpd_power_state dt/bindings: Update binding for PM domain idle states PM / Domains: Abstract genpd locking
PM / Domains: Support IRQ safe PM domains
PM / doc: Update device documentation for devices in IRQ safe PM
domains

Quoted 8 lines

 .../devicetree/bindings/power/power_domain.txt     |  43 +++
 Documentation/power/devices.txt                    |   9 +-
 arch/arm/mach-imx/gpc.c                            |  17 +-
 drivers/base/power/domain.c                        | 358
+++++++++++++++++----
 include/linux/pm_domain.h                          |  28 +-
 5 files changed, 383 insertions(+), 72 deletions(-)

Rafael, Lina,

This looks good to me! Unless any other objections, I suggest to apply this to get it tested in linux-next.

Quoted 6 lines

Quoted 3 lines

Kind regards
Uffe

Rafael,

If there are no objections, could you pick this patch for linux-next?

It is in my queue, but not at the top yet.

Thanks,
Rafael

Quoted 66 lines · Rafael J. Wysocki

Quoted 64 lines · Lina Iyer

Quoted 62 lines · Ulf Hansson

Quoted 42 lines · Lina Iyer

Hi all,

Changes since v2 [3] -
- Addressed review comments from v2.
- domain-idle-states documentation updated
- fixed compiler issues with imx driver
- minor code change in pm_domains.c
- The series is available at [4].

Changes since v1 [2] -
- Addressed review comments from v1.
- Fixes around dynamic allocation of genpd states
- Used OF method for iterating phandles
- Updated documentation, examples
- Rename state variable (provider -> fwnode)
- The series is available at [3].

The changes from [1] are -
- Allocating memory for domain idle states dynamically
- Conform to naming conventions for internal and exported genpd functions
- DT binding example for domain-idle-state
- Use fwnode instead of of_node
- Handle atomic case for removal of PM Domain
- Rebase on top of Rafael's pm/genpd tree

Thanks,
Lina

Lina Iyer (8):
PM / Domains: Make genpd state allocation dynamic
PM / Domain: Add residency property to genpd states PM / Domains: Allow domain power states to be read from DT PM / Domains: Save the fwnode in genpd_power_state dt/bindings: Update binding for PM domain idle states PM / Domains: Abstract genpd locking
PM / Domains: Support IRQ safe PM domains
PM / doc: Update device documentation for devices in IRQ safe PM
domains

Quoted 8 lines

 .../devicetree/bindings/power/power_domain.txt     |  43 +++
 Documentation/power/devices.txt                    |   9 +-
 arch/arm/mach-imx/gpc.c                            |  17 +-
 drivers/base/power/domain.c                        | 358
+++++++++++++++++----
 include/linux/pm_domain.h                          |  28 +-
 5 files changed, 383 insertions(+), 72 deletions(-)

Rafael, Lina,

This looks good to me! Unless any other objections, I suggest to apply this to get it tested in linux-next.

Kind regards
Uffe

Quoted 7 lines

Quoted 3 lines

Rafael,

If there are no objections, could you pick this patch for linux-next?

It is in my queue, but not at the top yet.

Thank you Rafael.

Quoted 39 lines · Lina Iyer

Hi all,

Changes since v2 [3] -
- Addressed review comments from v2.
- domain-idle-states documentation updated
- fixed compiler issues with imx driver
- minor code change in pm_domains.c
- The series is available at [4].

Changes since v1 [2] -
- Addressed review comments from v1.
- Fixes around dynamic allocation of genpd states
- Used OF method for iterating phandles
- Updated documentation, examples
- Rename state variable (provider -> fwnode)
- The series is available at [3].

The changes from [1] are -
- Allocating memory for domain idle states dynamically
- Conform to naming conventions for internal and exported genpd functions
- DT binding example for domain-idle-state
- Use fwnode instead of of_node
- Handle atomic case for removal of PM Domain
- Rebase on top of Rafael's pm/genpd tree

Thanks,
Lina

Lina Iyer (8):
PM / Domains: Make genpd state allocation dynamic
PM / Domain: Add residency property to genpd states PM / Domains: Allow domain power states to be read from DT PM / Domains: Save the fwnode in genpd_power_state dt/bindings: Update binding for PM domain idle states PM / Domains: Abstract genpd locking
PM / Domains: Support IRQ safe PM domains
PM / doc: Update device documentation for devices in IRQ safe PM
domains

Quoted 7 lines

 .../devicetree/bindings/power/power_domain.txt     |  43 +++
 Documentation/power/devices.txt                    |   9 +-
 arch/arm/mach-imx/gpc.c                            |  17 +-
 drivers/base/power/domain.c                        | 358 +++++++++++++++++----
 include/linux/pm_domain.h                          |  28 +-
 5 files changed, 383 insertions(+), 72 deletions(-)

Rafael, Lina,

This looks good to me! Unless any other objections, I suggest to apply this to get it tested in linux-next.