PM / Domains: Generic OF-based support and cleanups
Subsystems (12)
cover PM / Domains: Generic OF-based support and cleanups
Parts of this patchset has been posted earlier. To be able to smoothly continue my work in re-factoring genpd I have collected patches into this patchset.
The complete patchset is available at the linux-pm_linux-next_genpd branch at:
git.linaro.org/people/ulf.hansson/linux-2.6.git
This branch is based upon Rafael's linux-pm tree's linux-next branch.
And important note. There are dependencies througout this patchset, which means the all need to go together. I suggest we use Rafael's tree, thus I seek for acks from the affected ARM SoC maintainers.
Tomasz Figa (3):
base: power: Add generic OF-based power domain look-up
drivercore: Bind/unbind power domain on probe/remove
ARM: exynos: Move to generic power domain bindings
Ulf Hansson (21):
PM / Domains: Ignore callbacks for subsys generic_pm_domain_data PM / Domains: Remove the pm_genpd_add|remove_callbacks APIs PM / Domains: Remove system PM callbacks from gpd_dev_ops
ARM: shmobile: Drop dev_irq_safe from r8a7779 genpd config
ARM: shmobile: Drop dev_irq_safe from R-mobile genpd config PM / Domains: Remove dev_irq_safe from genpd config PM / Domains: Remove redundant check for CONFIG_PM
PM / Domains: Remove legacy API for adding devices through DT PM / Domains: Remove pm_genpd_syscore_switch() API
PM / Domains: Remove genpd_queue_power_off_work() API PM / Domains: Add late_initcall to disable unused domains
ARM: exynos: Leave disabling of unused pm domains to genpd
ARM: s3c64xx: Leave disabling of unused pm domains to genpd
drivers: sh: Leave disabling of unused pm domains to genpd PM / Domains: Remove default_stop_ok() API
dt: bindings: ux500: Add documentation for power domains
dt: bindings: ux500: Add header for power domains specifiers
ARM: ux500: Initial support for power domains
ARM: ux500: Enable Kconfig for the generic power domain
ARM: ux500: Add DT node for ux500 power domains
ARM: ux500: Add sdi[n] devices to VAPE power domain
.../bindings/arm/exynos/power_domain.txt | 12 +- .../devicetree/bindings/arm/ux500/power_domain.txt | 35 ++ .../devicetree/bindings/power/power_domain.txt | 51 ++ arch/arm/boot/dts/ste-dbx5x0.dtsi | 11 + arch/arm/mach-exynos/exynos.c | 1 - arch/arm/mach-exynos/pm_domains.c | 81 +-- arch/arm/mach-s3c64xx/common.c | 5 - arch/arm/mach-s3c64xx/common.h | 7 - arch/arm/mach-s3c64xx/mach-anw6410.c | 1 - arch/arm/mach-s3c64xx/mach-crag6410.c | 1 - arch/arm/mach-s3c64xx/mach-hmt.c | 1 - arch/arm/mach-s3c64xx/mach-mini6410.c | 1 - arch/arm/mach-s3c64xx/mach-ncp.c | 1 - arch/arm/mach-s3c64xx/mach-real6410.c | 1 - arch/arm/mach-s3c64xx/mach-smartq5.c | 1 - arch/arm/mach-s3c64xx/mach-smartq7.c | 1 - arch/arm/mach-s3c64xx/mach-smdk6400.c | 1 - arch/arm/mach-s3c64xx/mach-smdk6410.c | 1 - arch/arm/mach-s3c64xx/pm.c | 7 - arch/arm/mach-shmobile/pm-r8a7779.c | 1 - arch/arm/mach-shmobile/pm-rmobile.c | 1 - arch/arm/mach-ux500/Kconfig | 1 + arch/arm/mach-ux500/Makefile | 1 + arch/arm/mach-ux500/pm.c | 4 + arch/arm/mach-ux500/pm_domains.c | 77 +++ arch/arm/mach-ux500/pm_domains.h | 17 + drivers/base/dd.c | 9 +- drivers/base/power/domain.c | 638 ++++++++++---------- drivers/base/power/domain_governor.c | 7 +- drivers/sh/pm_runtime.c | 11 - include/dt-bindings/arm/ux500_pm_domains.h | 15 + include/linux/pm_domain.h | 107 ++-- kernel/power/Kconfig | 4 + 33 files changed, 593 insertions(+), 520 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/ux500/power_domain.txt create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt create mode 100644 arch/arm/mach-ux500/pm_domains.c create mode 100644 arch/arm/mach-ux500/pm_domains.h create mode 100644 include/dt-bindings/arm/ux500_pm_domains.h
Signature · 1 line
1.7.9.5
PATCH 1/24 base: power: Add generic OF-based power domain look-up
From: Tomasz Figa <[email protected]>
This patch introduces generic code to perform power domain look-up using device tree and automatically bind devices to their power domains. Generic device tree binding is introduced to specify power domains of devices in their device tree nodes.
Backwards compatibility with legacy Samsung-specific power domain bindings is provided, but for now the new code is not compiled when CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This will change as soon as Exynos power domain code gets converted to use the generic framework in further patch.
--- .../devicetree/bindings/power/power_domain.txt | 51 ++++ drivers/base/power/domain.c | 283 ++++++++++++++++++++ include/linux/pm_domain.h | 46 ++++ kernel/power/Kconfig | 4 + 4 files changed, 384 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
Documentation/devicetree/bindings/power/power_domain.txt new file +51 -0
@@ -0,0 +1,51 @@ +* Generic power domains + +System on chip designs are often divided into multiple power domains that +can be used for power gating of selected IP blocks for power saving by +reduced leakage current. + +This device tree binding can be used to bind power domain consumer devices +with their power domains provided by power domain providers. A power domain +provider can be represented by any node in the device tree and can provide +one or more power domains. A consumer node can refer to the provider by +a phandle and a set of phandle arguments (so called power domain specifier) +of length specified by #power-domain-cells property in the power domain +provider node. + +==Power domain providers== + +Required properties: + - #power-domain-cells : Number of cells in a power domain specifier; + Typically 0 for nodes representing a single power domain and 1 for nodes + providing multiple power domains (e.g. power controllers), but can be + any value as specified by device tree binding documentation of particular + provider. + +Example: + + power: power-controller at 12340000 { + compatible = "foo,power-controller"; + reg = <0x12340000 0x1000>; + #power-domain-cells = <1>; + }; + +The node above defines a power controller that is a power domain provider +and expects one cell as its phandle argument. + +==Power domain consumers== + +Required properties: + - power-domains : A phandle and power domain specifier as defined by bindings + of power controller specified by phandle. + +Example: + + leaky-device at 12350000 { + compatible = "foo,i-leak-current"; + reg = <0x12350000 0x1000>; + power-domains = <&power 0>; + }; + +The node above defines a typical power domain consumer device, which is located +inside power domain with index 0 of power controller represented by node with +label "power".
drivers/base/power/domain.c +283 -0
292 lines not on this page · raw message
include/linux/pm_domain.h +46 -0
50 lines not on this page · raw message
kernel/power/Kconfig +4 -0
@@ -305,6 +305,10 @@ config PM_GENERIC_DOMAINS_RUNTIME def_bool y depends on PM_RUNTIME && PM_GENERIC_DOMAINS +config PM_GENERIC_DOMAINS_OF + def_bool y + depends on PM_GENERIC_DOMAINS && OF && !ARCH_EXYNOS + config CPU_PM bool depends on SUSPEND || CPU_IDLE
Signature · 1 line
1.7.9.5
PATCH 2/24 drivercore: Bind/unbind power domain on probe/remove
In reply to Ulf HanssonFrom: Tomasz Figa <[email protected]>
On a number of platforms, devices are part of controllable power domains, which need to be enabled before such devices can be accessed and may be powered down when the device is idle to save some power. This means that on systems that support power domain control using generic power domains subsystem, it is necessary to add device to its power domain before binding a driver to it and remove it from its power domain after its driver is unbound to make sure that an unused device does not affect power domain state.
Since this is not limited to particular busses and specific archs/platforms, it is more convenient to do the above directly in driver core, just as done with pinctrl default configuration. This patch adds necessary code to really_probe() and __device_release_driver() to achieve this and maintain consistent stack-like ordering of operations happening when binding and unbinding a driver.
--- drivers/base/dd.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/base/dd.c +8 -1
@@ -23,6 +23,7 @@#include <linux/kthread.h> #include <linux/wait.h> #include <linux/async.h> +#include <linux/pm_domain.h> #include <linux/pm_runtime.h> #include <linux/pinctrl/devinfo.h>
@@ -287,6 +288,11 @@ static int really_probe(struct device *dev, struct device_driver *drv) dev->driver = drv; +/* If using genpd, bind power domain now before probing */ + ret =genpd_bind_domain (dev); +if (ret) + goto probe_failed; +/* If using pinctrl, bind pins now before probing */ ret =pinctrl_bind_pins (dev);if (ret)
@@ -317,6 +323,7 @@ static int really_probe(struct device *dev, struct device_driver *drv) probe_failed:devres_release_all (dev);driver_sysfs_remove (dev); +genpd_unbind_domain (dev); dev->driver =NULL ;dev_set_drvdata (dev,NULL );
@@ -530,7 +537,7 @@ static void __device_release_driver(struct device *dev)blocking_notifier_call_chain (&dev->bus->p->bus_notifier,BUS_NOTIFY_UNBOUND_DRIVER , dev); - +genpd_unbind_domain (dev); } }
Signature · 1 line
1.7.9.5
Rafael J. Wysocki
maintainerPATCH 2/24 drivercore: Bind/unbind power domain on probe/remove
Quoted 11 lines · Ulf Hansson
From: Tomasz Figa <[email protected]>
On a number of platforms, devices are part of controllable power domains, which need to be enabled before such devices can be accessed and may be powered down when the device is idle to save some power. This means that on systems that support power domain control using generic power domains subsystem, it is necessary to add device to its power domain before binding a driver to it and remove it from its power domain after its driver is unbound to make sure that an unused device does not affect power domain state.
Quoted 2 lines
Since this is not limited to particular busses and specific archs/platforms,
Actually, this isn't correrct. It is limited to the platforms that use Device Trees now.
Moreover, it is not consistent with the way we add devices to the ACPI PM domain, which is the ACPI counterpart of this.
Rafael
PATCH 2/24 drivercore: Bind/unbind power domain on probe/remove
Quoted 12 lines · Rafael J. Wysocki
Quoted 11 lines · Ulf Hansson
From: Tomasz Figa <[email protected]>
On a number of platforms, devices are part of controllable power domains, which need to be enabled before such devices can be accessed and may be powered down when the device is idle to save some power. This means that on systems that support power domain control using generic power domains subsystem, it is necessary to add device to its power domain before binding a driver to it and remove it from its power domain after its driver is unbound to make sure that an unused device does not affect power domain state.
Quoted 5 lines
Quoted 2 lines
Since this is not limited to particular busses and specific archs/platforms,
Actually, this isn't correrct. It is limited to the platforms that use Device Trees now.
Correct, we should update the commit message/docs.
Quoted 3 lines
Moreover, it is not consistent with the way we add devices to the ACPI PM domain, which is the ACPI counterpart of this.
I am not sure why you think consistency for ACPI is important here. ACPI PM will still be able to handle it's domain/device registering as before. There are even other pm_domains that don't use genpd which need to handle this themselves.
Or are you saying that you prefer bus notifiers in favour of making use of the driver core for this matter? Shouldn't the driver core handle most of the common things for a device driver? Let's compare how the pinctrls are being managed in the driver core, for example.
Kind regards
Ulf Hansson
Quoted 2 lines
Rafael
PATCH 2/24 drivercore: Bind/unbind power domain on probe/remove
Quoted 22 lines · Ulf Hansson
Quoted 12 lines · Rafael J. Wysocki
Quoted 11 lines · Ulf Hansson
From: Tomasz Figa <[email protected]>
On a number of platforms, devices are part of controllable power domains, which need to be enabled before such devices can be accessed and may be powered down when the device is idle to save some power. This means that on systems that support power domain control using generic power domains subsystem, it is necessary to add device to its power domain before binding a driver to it and remove it from its power domain after its driver is unbound to make sure that an unused device does not affect power domain state.
Quoted 5 lines
Quoted 2 lines
Since this is not limited to particular busses and specific archs/platforms,
Actually, this isn't correrct. It is limited to the platforms that use Device Trees now.
Correct, we should update the commit message/docs.
Quoted 1 line
Quoted 7 lines
Quoted 2 lines
Moreover, it is not consistent with the way we add devices to the ACPI PM domain, which is the ACPI counterpart of this.
I am not sure why you think consistency for ACPI is important here. ACPI PM will still be able to handle it's domain/device registering as before. There are even other
pm_domainsthat don't use genpd which need to handle this themselves.
My point is that doing things like that in different places for different firmware interfaces is confusing and likely to lead to coding mistakes in the future.
Quoted 2 lines
Or are you saying that you prefer bus notifiers in favour of making use of the driver core for this matter?
Well, please grep for acpi_dev_pm_attach() and see where it is done. Surely not in drivers/base/dd.c. Also I'm not sure why you're talking about bus notifiers in this context.
Quoted 2 lines
Shouldn't the driver core handle most of the common things for a device driver?
Common, yes. Platform-specific, no.
Quoted 2 lines
Let's compare how the pinctrls are being managed in the driver core, for example.
pinctrl has Device Trees support only at the moment (as far as firmware interfaces go) and quite frankly I'm not sure if/how we'll need to change it to cover ACPI as well.
But for power domains, please keep that stuff away from dd.c. That is, unless Greg specifically disagrees with me and decides to apply this patch regardless. :-)
Rafael
Greg Kroah-Hartman
maintainerPATCH 2/24 drivercore: Bind/unbind power domain on probe/remove
Quoted 50 lines · Rafael J. Wysocki
Quoted 22 lines · Ulf Hansson
Quoted 12 lines · Rafael J. Wysocki
Quoted 11 lines · Ulf Hansson
From: Tomasz Figa <[email protected]>
On a number of platforms, devices are part of controllable power domains, which need to be enabled before such devices can be accessed and may be powered down when the device is idle to save some power. This means that on systems that support power domain control using generic power domains subsystem, it is necessary to add device to its power domain before binding a driver to it and remove it from its power domain after its driver is unbound to make sure that an unused device does not affect power domain state.
Quoted 5 lines
Quoted 2 lines
Since this is not limited to particular busses and specific archs/platforms,
Actually, this isn't correrct. It is limited to the platforms that use Device Trees now.
Correct, we should update the commit message/docs.
Quoted 1 line
Quoted 7 lines
Quoted 2 lines
Moreover, it is not consistent with the way we add devices to the ACPI PM domain, which is the ACPI counterpart of this.
I am not sure why you think consistency for ACPI is important here. ACPI PM will still be able to handle it's domain/device registering as before. There are even other
pm_domainsthat don't use genpd which need to handle this themselves.My point is that doing things like that in different places for different firmware interfaces is confusing and likely to lead to coding mistakes in the future.
Quoted 2 lines
Or are you saying that you prefer bus notifiers in favour of making use of the driver core for this matter?
Well, please grep for
acpi_dev_pm_attach()and see where it is done. Surely not indrivers/base/dd.c. Also I'm not sure why you're talking about bus notifiers in this context.Quoted 2 lines
Shouldn't the driver core handle most of the common things for a device driver?
Common, yes. Platform-specific, no.
Quoted 2 lines
Let's compare how the pinctrls are being managed in the driver core, for example.
Quoted 7 lines
pinctrl has Device Trees support only at the moment (as far as firmware interfaces go) and quite frankly I'm not sure if/how we'll need to change it to cover ACPI as well.
But for power domains, please keep that stuff away from
dd.c. That is, unless Greg specifically disagrees with me and decides to apply this patch regardless. :-)
Nope, no disagreement from me toward you at all here, keep up the good work :)
greg k-h
PATCH 2/24 drivercore: Bind/unbind power domain on probe/remove
Quoted 55 lines · Greg Kroah-Hartman
Quoted 54 lines · Rafael J. Wysocki
Quoted 22 lines · Ulf Hansson
Quoted 12 lines · Rafael J. Wysocki
Quoted 11 lines · Ulf Hansson
From: Tomasz Figa <[email protected]>
On a number of platforms, devices are part of controllable power domains, which need to be enabled before such devices can be accessed and may be powered down when the device is idle to save some power. This means that on systems that support power domain control using generic power domains subsystem, it is necessary to add device to its power domain before binding a driver to it and remove it from its power domain after its driver is unbound to make sure that an unused device does not affect power domain state.
Quoted 5 lines
Quoted 2 lines
Since this is not limited to particular busses and specific archs/platforms,
Actually, this isn't correrct. It is limited to the platforms that use Device Trees now.
Correct, we should update the commit message/docs.
Quoted 1 line
Quoted 7 lines
Quoted 2 lines
Moreover, it is not consistent with the way we add devices to the ACPI PM domain, which is the ACPI counterpart of this.
I am not sure why you think consistency for ACPI is important here. ACPI PM will still be able to handle it's domain/device registering as before. There are even other
pm_domainsthat don't use genpd which need to handle this themselves.My point is that doing things like that in different places for different firmware interfaces is confusing and likely to lead to coding mistakes in the future.
Quoted 2 lines
Or are you saying that you prefer bus notifiers in favour of making use of the driver core for this matter?
Well, please grep for
acpi_dev_pm_attach()and see where it is done. Surely not indrivers/base/dd.c. Also I'm not sure why you're talking about bus notifiers in this context.Quoted 2 lines
Shouldn't the driver core handle most of the common things for a device driver?
Common, yes. Platform-specific, no.
Quoted 2 lines
Let's compare how the pinctrls are being managed in the driver core, for example.
pinctrl has Device Trees support only at the moment (as far as firmware interfaces go) and quite frankly I'm not sure if/how we'll need to change it to cover ACPI as well.
Quoted 6 lines
Quoted 3 lines
But for power domains, please keep that stuff away from
dd.c. That is, unless Greg specifically disagrees with me and decides to apply this patch regardless. :-)Nope, no disagreement from me toward you at all here, keep up the good work :)
OK, so proposed solution is to put this in:
- platform_drv_probe(),
- spi_drv_probe(),
- i2c_device_probe(),
- amba_probe(),
...
- and any other bus type, which can have devices instantiated from DT.
If this is what you mean, I still think putting this in dd is cleaner and more scalable, but I'm not going to insist, as I believe you have good reasons to prefer this approach over current one.
Best regards,
Tomasz
PATCH 2/24 drivercore: Bind/unbind power domain on probe/remove
Quoted 70 lines · Tomasz Figa
Quoted 55 lines · Greg Kroah-Hartman
Quoted 54 lines · Rafael J. Wysocki
Quoted 22 lines · Ulf Hansson
Quoted 12 lines · Rafael J. Wysocki
Quoted 11 lines · Ulf Hansson
From: Tomasz Figa <[email protected]>
On a number of platforms, devices are part of controllable power domains, which need to be enabled before such devices can be accessed and may be powered down when the device is idle to save some power. This means that on systems that support power domain control using generic power domains subsystem, it is necessary to add device to its power domain before binding a driver to it and remove it from its power domain after its driver is unbound to make sure that an unused device does not affect power domain state.
Quoted 5 lines
Quoted 2 lines
Since this is not limited to particular busses and specific archs/platforms,
Actually, this isn't correrct. It is limited to the platforms that use Device Trees now.
Correct, we should update the commit message/docs.
Quoted 1 line
Quoted 7 lines
Quoted 2 lines
Moreover, it is not consistent with the way we add devices to the ACPI PM domain, which is the ACPI counterpart of this.
I am not sure why you think consistency for ACPI is important here. ACPI PM will still be able to handle it's domain/device registering as before. There are even other
pm_domainsthat don't use genpd which need to handle this themselves.My point is that doing things like that in different places for different firmware interfaces is confusing and likely to lead to coding mistakes in the future.
Quoted 2 lines
Or are you saying that you prefer bus notifiers in favour of making use of the driver core for this matter?
Well, please grep for
acpi_dev_pm_attach()and see where it is done. Surely not indrivers/base/dd.c. Also I'm not sure why you're talking about bus notifiers in this context.Quoted 2 lines
Shouldn't the driver core handle most of the common things for a device driver?
Common, yes. Platform-specific, no.
Quoted 2 lines
Let's compare how the pinctrls are being managed in the driver core, for example.
pinctrl has Device Trees support only at the moment (as far as firmware interfaces go) and quite frankly I'm not sure if/how we'll need to change it to cover ACPI as well.
Quoted 6 lines
Quoted 3 lines
But for power domains, please keep that stuff away from
dd.c. That is, unless Greg specifically disagrees with me and decides to apply this patch regardless. :-)Nope, no disagreement from me toward you at all here, keep up the good work :)
OK, so proposed solution is to put this in:
-
platform_drv_probe(),
-spi_drv_probe(),
-i2c_device_probe(),
-amba_probe(),
Quoted 7 lines
...
- and any other bus type, which can have devices instantiated from DT.
If this is what you mean, I still think putting this in dd is cleaner and more scalable, but I'm not going to insist, as I believe you have good reasons to prefer this approach over current one.
I am not so sure we should ignore scalability.
Currently there are SoCs those that uses bus notifiers to handle the device registration for it's pm_domain. When each of them converts to use bus' ->probe() function instead, they will have their own version of acpi_dev_pm_attach(), and the scalability becomes an issue.
An option could be to invent a common "pm_domain_attach_dev() API", which will check what kind of power domain the device may reside in. In principle invoke acpi_dev_pm_attach() and if no attachment happens, try genpd_bind_domain().
Kind regards
Ulf Hansson
PATCH 2/24 drivercore: Bind/unbind power domain on probe/remove
In reply to Tomasz FigaQuoted 63 lines · Tomasz Figa
Quoted 55 lines · Greg Kroah-Hartman
Quoted 54 lines · Rafael J. Wysocki
Quoted 22 lines · Ulf Hansson
Quoted 12 lines · Rafael J. Wysocki
Quoted 11 lines · Ulf Hansson
From: Tomasz Figa <[email protected]>
On a number of platforms, devices are part of controllable power domains, which need to be enabled before such devices can be accessed and may be powered down when the device is idle to save some power. This means that on systems that support power domain control using generic power domains subsystem, it is necessary to add device to its power domain before binding a driver to it and remove it from its power domain after its driver is unbound to make sure that an unused device does not affect power domain state.
Quoted 5 lines
Quoted 2 lines
Since this is not limited to particular busses and specific archs/platforms,
Actually, this isn't correrct. It is limited to the platforms that use Device Trees now.
Correct, we should update the commit message/docs.
Quoted 1 line
Quoted 7 lines
Quoted 2 lines
Moreover, it is not consistent with the way we add devices to the ACPI PM domain, which is the ACPI counterpart of this.
I am not sure why you think consistency for ACPI is important here. ACPI PM will still be able to handle it's domain/device registering as before. There are even other
pm_domainsthat don't use genpd which need to handle this themselves.My point is that doing things like that in different places for different firmware interfaces is confusing and likely to lead to coding mistakes in the future.
Quoted 2 lines
Or are you saying that you prefer bus notifiers in favour of making use of the driver core for this matter?
Well, please grep for
acpi_dev_pm_attach()and see where it is done. Surely not indrivers/base/dd.c. Also I'm not sure why you're talking about bus notifiers in this context.Quoted 2 lines
Shouldn't the driver core handle most of the common things for a device driver?
Common, yes. Platform-specific, no.
Quoted 2 lines
Let's compare how the pinctrls are being managed in the driver core, for example.
pinctrl has Device Trees support only at the moment (as far as firmware interfaces go) and quite frankly I'm not sure if/how we'll need to change it to cover ACPI as well.
Quoted 6 lines
Quoted 3 lines
But for power domains, please keep that stuff away from
dd.c. That is, unless Greg specifically disagrees with me and decides to apply this patch regardless. :-)Nope, no disagreement from me toward you at all here, keep up the good work :)
Quoted 6 lines
OK, so proposed solution is to put this in:
-
platform_drv_probe(),
-spi_drv_probe(),
-i2c_device_probe(),
-amba_probe(),
Yes. Specifically, those are bus types that don't do their own power management.
Quoted 3 lines
...
- and any other bus type, which can have devices instantiated from DT.
And doesn't do its own power management, in which case it will need to incorporate PM domains handling into its code in a more sophisticated way, most likely.
Quoted 3 lines
If this is what you mean, I still think putting this in dd is cleaner and more scalable, but I'm not going to insist, as I believe you have good reasons to prefer this approach over current one.
It may look cleaner, but need not be correct.
Rafael
PATCH 2/24 drivercore: Bind/unbind power domain on probe/remove
Quoted 11 lines · Rafael J. Wysocki
Quoted 6 lines · Tomasz Figa
OK, so proposed solution is to put this in:
-
platform_drv_probe(),
-spi_drv_probe(),
-i2c_device_probe(),
-amba_probe(),Yes. Specifically, those are bus types that don't do their own power management.
This sounds tedious. Can we not instead introduce some generic helpers
which all such buses call/use and then implement the hooks in there
(along with anything else that they should all do)? There must be other
things that all these buses are having to cut'n'paste.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140612/60325df9/attachment-0001.sig>
PATCH 2/24 drivercore: Bind/unbind power domain on probe/remove
Quoted 10 lines · Mark Brown
Quoted 8 lines · Rafael J. Wysocki
Quoted 6 lines · Tomasz Figa
OK, so proposed solution is to put this in:
-
platform_drv_probe(),
-spi_drv_probe(),
-i2c_device_probe(),
-amba_probe(),
Quoted 6 lines
Quoted 2 lines
Yes. Specifically, those are bus types that don't do their own power management.
This sounds tedious. Can we not instead introduce some generic helpers which all such buses call/use and then implement the hooks in there (along with anything else that they should all do)?
Well, good idea.
Quoted 1 line
There must be other things that all these buses are having to cut'n'paste.
Quite likely.
Rafael
PATCH 2/24 drivercore: Bind/unbind power domain on probe/remove
In reply to Tomasz FigaQuoted 65 lines · Tomasz Figa
Quoted 55 lines · Greg Kroah-Hartman
Quoted 54 lines · Rafael J. Wysocki
Quoted 22 lines · Ulf Hansson
Quoted 12 lines · Rafael J. Wysocki
Quoted 11 lines · Ulf Hansson
From: Tomasz Figa <[email protected]>
On a number of platforms, devices are part of controllable power domains, which need to be enabled before such devices can be accessed and may be powered down when the device is idle to save some power. This means that on systems that support power domain control using generic power domains subsystem, it is necessary to add device to its power domain before binding a driver to it and remove it from its power domain after its driver is unbound to make sure that an unused device does not affect power domain state.
Quoted 5 lines
Quoted 2 lines
Since this is not limited to particular busses and specific archs/platforms,
Actually, this isn't correrct. It is limited to the platforms that use Device Trees now.
Correct, we should update the commit message/docs.
Quoted 1 line
Quoted 7 lines
Quoted 2 lines
Moreover, it is not consistent with the way we add devices to the ACPI PM domain, which is the ACPI counterpart of this.
I am not sure why you think consistency for ACPI is important here. ACPI PM will still be able to handle it's domain/device registering as before. There are even other
pm_domainsthat don't use genpd which need to handle this themselves.My point is that doing things like that in different places for different firmware interfaces is confusing and likely to lead to coding mistakes in the future.
Quoted 2 lines
Or are you saying that you prefer bus notifiers in favour of making use of the driver core for this matter?
Well, please grep for
acpi_dev_pm_attach()and see where it is done. Surely not indrivers/base/dd.c. Also I'm not sure why you're talking about bus notifiers in this context.Quoted 2 lines
Shouldn't the driver core handle most of the common things for a device driver?
Common, yes. Platform-specific, no.
Quoted 2 lines
Let's compare how the pinctrls are being managed in the driver core, for example.
pinctrl has Device Trees support only at the moment (as far as firmware interfaces go) and quite frankly I'm not sure if/how we'll need to change it to cover ACPI as well.
Quoted 6 lines
Quoted 3 lines
But for power domains, please keep that stuff away from
dd.c. That is, unless Greg specifically disagrees with me and decides to apply this patch regardless. :-)Nope, no disagreement from me toward you at all here, keep up the good work :)
OK, so proposed solution is to put this in:
Quoted 8 lines
-
platform_drv_probe(),
-spi_drv_probe(),
-i2c_device_probe(),
-amba_probe(),...
- and any other bus type, which can have devices instantiated from DT.
Since this is a DT feature, what about calling __pm_genpd_of_add_device() when the power-domain nodes are discovered?
Kevin
PATCH 2/24 drivercore: Bind/unbind power domain on probe/remove
Quoted 72 lines · Kevin Hilman
Quoted 70 lines · Tomasz Figa
Quoted 55 lines · Greg Kroah-Hartman
Quoted 54 lines · Rafael J. Wysocki
Quoted 22 lines · Ulf Hansson
Quoted 12 lines · Rafael J. Wysocki
Quoted 11 lines · Ulf Hansson
From: Tomasz Figa <[email protected]>
On a number of platforms, devices are part of controllable power domains, which need to be enabled before such devices can be accessed and may be powered down when the device is idle to save some power. This means that on systems that support power domain control using generic power domains subsystem, it is necessary to add device to its power domain before binding a driver to it and remove it from its power domain after its driver is unbound to make sure that an unused device does not affect power domain state.
Quoted 5 lines
Quoted 2 lines
Since this is not limited to particular busses and specific archs/platforms,
Actually, this isn't correrct. It is limited to the platforms that use Device Trees now.
Correct, we should update the commit message/docs.
Quoted 1 line
Quoted 7 lines
Quoted 2 lines
Moreover, it is not consistent with the way we add devices to the ACPI PM domain, which is the ACPI counterpart of this.
I am not sure why you think consistency for ACPI is important here. ACPI PM will still be able to handle it's domain/device registering as before. There are even other
pm_domainsthat don't use genpd which need to handle this themselves.My point is that doing things like that in different places for different firmware interfaces is confusing and likely to lead to coding mistakes in the future.
Quoted 2 lines
Or are you saying that you prefer bus notifiers in favour of making use of the driver core for this matter?
Well, please grep for
acpi_dev_pm_attach()and see where it is done. Surely not indrivers/base/dd.c. Also I'm not sure why you're talking about bus notifiers in this context.Quoted 2 lines
Shouldn't the driver core handle most of the common things for a device driver?
Common, yes. Platform-specific, no.
Quoted 2 lines
Let's compare how the pinctrls are being managed in the driver core, for example.
pinctrl has Device Trees support only at the moment (as far as firmware interfaces go) and quite frankly I'm not sure if/how we'll need to change it to cover ACPI as well.
Quoted 6 lines
Quoted 3 lines
But for power domains, please keep that stuff away from
dd.c. That is, unless Greg specifically disagrees with me and decides to apply this patch regardless. :-)Nope, no disagreement from me toward you at all here, keep up the good work :)
OK, so proposed solution is to put this in:
-
platform_drv_probe(),
-spi_drv_probe(),
-i2c_device_probe(),
-amba_probe(),
Quoted 6 lines
Quoted 3 lines
...
- and any other bus type, which can have devices instantiated from DT.
Since this is a DT feature, what about calling
__pm_genpd_of_add_device()when the power-domain nodes are discovered?
I'm not sure how this would work. Could you elaborate on this?
Best regards,
Tomasz
PATCH 3/24 ARM: exynos: Move to generic power domain bindings
In reply to Ulf HanssonFrom: Tomasz Figa <[email protected]>
This patch moves Exynos power domain code to use the new generic power domain look-up framework introduced by previous patch, allowing the new code to be compiled with CONFIG_ARCH_EXYNOS selected as well.
--- .../bindings/arm/exynos/power_domain.txt | 12 ++- arch/arm/mach-exynos/pm_domains.c | 81 +------------------- kernel/power/Kconfig | 2 +- 3 files changed, 7 insertions(+), 88 deletions(-)
Documentation/devicetree/bindings/arm/exynos/power_domain.txt +5 -7
@@ -8,6 +8,8 @@ Required Properties: * samsung,exynos4210-pd - for exynos4210 type power domain. - reg: physical base address of the controller and length of memory mapped region. +- #power-domain-cells: number of cells in power domain specifier; + must be 0. Node of a device using power domains must have a samsung,power-domain property defined with a phandle to respective power domain.
@@ -17,12 +19,8 @@ Example: lcd0: power-domain-lcd0 { compatible = "samsung,exynos4210-pd"; reg = <0x10023C00 0x10>; + #power-domain-cells = <0>; }; -Example of the node using power domain: - - node { - /* ... */ - samsung,power-domain = <&lcd0>; - /* ... */ - }; +See Documentation/devicetree/bindings/power/power_domain.txt for description +of consumer-side bindings.
arch/arm/mach-exynos/pm_domains.c +1 -80
107 lines not on this page · raw message
kernel/power/Kconfig +1 -1
@@ -307,7 +307,7 @@ config PM_GENERIC_DOMAINS_RUNTIME config PM_GENERIC_DOMAINS_OF def_bool y - depends on PM_GENERIC_DOMAINS && OF && !ARCH_EXYNOS + depends on PM_GENERIC_DOMAINS && OF config CPU_PM bool
Signature · 1 line
1.7.9.5
PATCH 4/24 PM / Domains: Ignore callbacks for subsys generic_pm_domain_data
In reply to Ulf HanssonIn a step of simplifying the generic power domain let's move away from using these callbacks.
--- drivers/base/power/domain.c | 131 +++---------------------------------------- 1 file changed, 8 insertions(+), 123 deletions(-)
drivers/base/power/domain.c +8 -123
@@ -26,10 +26,6 @@ __routine = genpd->dev_ops.callback; \if (__routine) { \ __ret =__routine (dev); \ - }else { \ - __routine =dev_gpd_data (dev)->ops.callback; \ -if (__routine) \ - __ret =__routine (dev); \ } \ __ret; \ })
@@ -1978,10 +1974,6 @@ static int pm_genpd_default_save_state(struct device *dev) {int (*cb)(struct device *__dev); - cb =dev_gpd_data (dev)->ops.save_state; -if (cb) -return cb (dev); -if (dev->type && dev->type->pm) cb = dev->type->pm->runtime_suspend;else if (dev->class && dev->class->pm)
@@ -2005,10 +1997,6 @@ static int pm_genpd_default_restore_state(struct device *dev) {int (*cb)(struct device *__dev); - cb =dev_gpd_data (dev)->ops.restore_state; -if (cb) -return cb (dev); -if (dev->type && dev->type->pm) cb = dev->type->pm->runtime_resume;else if (dev->class && dev->class->pm)
@@ -2024,109 +2012,6 @@ static int pm_genpd_default_restore_state(struct device *dev)return cb ?cb (dev) :0 ; } -#ifdef CONFIG_PM_SLEEP - -/** -* pm_genpd_default_suspend - Default "device suspend" for PM domians. -* @dev: Device to handle. -*/ -static int pm_genpd_default_suspend (struct device *dev) -{ -int (*cb)(struct device *__dev) =dev_gpd_data (dev)->ops.suspend; - -return cb ?cb (dev) :pm_generic_suspend (dev); -} - -/** -* pm_genpd_default_suspend_late - Default "late device suspend" for PM domians. -* @dev: Device to handle. -*/ -static int pm_genpd_default_suspend_late (struct device *dev) -{ -int (*cb)(struct device *__dev) =dev_gpd_data (dev)->ops.suspend_late; - -return cb ?cb (dev) :pm_generic_suspend_late (dev); -} - -/** -* pm_genpd_default_resume_early - Default "early device resume" for PM domians. -* @dev: Device to handle. -*/ -static int pm_genpd_default_resume_early (struct device *dev) -{ -int (*cb)(struct device *__dev) =dev_gpd_data (dev)->ops.resume_early; - -return cb ?cb (dev) :pm_generic_resume_early (dev); -} - -/** -* pm_genpd_default_resume - Default "device resume" for PM domians. -* @dev: Device to handle. -*/ -static int pm_genpd_default_resume (struct device *dev) -{ -int (*cb)(struct device *__dev) =dev_gpd_data (dev)->ops.resume; - -return cb ?cb (dev) :pm_generic_resume (dev); -} - -/** -* pm_genpd_default_freeze - Default "device freeze" for PM domians. -* @dev: Device to handle. -*/ -static int pm_genpd_default_freeze (struct device *dev) -{ -int (*cb)(struct device *__dev) =dev_gpd_data (dev)->ops.freeze; - -return cb ?cb (dev) :pm_generic_freeze (dev); -} - -/** -* pm_genpd_default_freeze_late - Default "late device freeze" for PM domians. -* @dev: Device to handle. -*/ -static int pm_genpd_default_freeze_late (struct device *dev) -{ -int (*cb)(struct device *__dev) =dev_gpd_data (dev)->ops.freeze_late; - -return cb ?cb (dev) :pm_generic_freeze_late (dev); -} - -/** -* pm_genpd_default_thaw_early - Default "early device thaw" for PM domians. -* @dev: Device to handle. -*/ -static int pm_genpd_default_thaw_early (struct device *dev) -{ -int (*cb)(struct device *__dev) =dev_gpd_data (dev)->ops.thaw_early; - -return cb ?cb (dev) :pm_generic_thaw_early (dev); -} - -/** -* pm_genpd_default_thaw - Default "device thaw" for PM domians. -* @dev: Device to handle. -*/ -static int pm_genpd_default_thaw (struct device *dev) -{ -int (*cb)(struct device *__dev) =dev_gpd_data (dev)->ops.thaw; - -return cb ?cb (dev) :pm_generic_thaw (dev); -} - -#else /* !CONFIG_PM_SLEEP */ - -#define pm_genpd_default_suspend NULL -#define pm_genpd_default_suspend_late NULL -#define pm_genpd_default_resume_early NULL -#define pm_genpd_default_resume NULL -#define pm_genpd_default_freeze NULL -#define pm_genpd_default_freeze_late NULL -#define pm_genpd_default_thaw_early NULL -#define pm_genpd_default_thaw NULL - -#endif /* !CONFIG_PM_SLEEP */ -/** * pm_genpd_init - Initialize a generic I/O PM domain object. * @genpd: PM domain object to initialize.
@@ -2178,14 +2063,14 @@ void pm_genpd_init(struct generic_pm_domain *genpd, genpd->domain.ops.complete = pm_genpd_complete; genpd->dev_ops.save_state = pm_genpd_default_save_state; genpd->dev_ops.restore_state = pm_genpd_default_restore_state; - genpd->dev_ops.suspend = pm_genpd_default_suspend; - genpd->dev_ops.suspend_late = pm_genpd_default_suspend_late; - genpd->dev_ops.resume_early = pm_genpd_default_resume_early; - genpd->dev_ops.resume = pm_genpd_default_resume; - genpd->dev_ops.freeze = pm_genpd_default_freeze; - genpd->dev_ops.freeze_late = pm_genpd_default_freeze_late; - genpd->dev_ops.thaw_early = pm_genpd_default_thaw_early; - genpd->dev_ops.thaw = pm_genpd_default_thaw; + genpd->dev_ops.suspend = pm_generic_suspend; + genpd->dev_ops.suspend_late = pm_generic_suspend_late; + genpd->dev_ops.resume_early = pm_generic_resume_early; + genpd->dev_ops.resume = pm_generic_resume; + genpd->dev_ops.freeze = pm_generic_freeze; + genpd->dev_ops.freeze_late = pm_generic_freeze_late; + genpd->dev_ops.thaw_early = pm_generic_thaw_early; + genpd->dev_ops.thaw = pm_generic_thaw;mutex_lock (&gpd_list_lock);list_add (&genpd->gpd_list_node, &gpd_list);mutex_unlock (&gpd_list_lock);
Signature · 1 line
1.7.9.5
PATCH 5/24 PM / Domains: Remove the pm_genpd_add|remove_callbacks APIs
In reply to Ulf HanssonThere are no users of these APIs. To simplify the generic power domain let's remove them.
--- drivers/base/power/domain.c | 106 ------------------------------------------- include/linux/pm_domain.h | 20 -------- 2 files changed, 126 deletions(-)
drivers/base/power/domain.c +0 -106
@@ -1741,112 +1741,6 @@ int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd, }/** -* pm_genpd_add_callbacks - Add PM domain callbacks to a given device. -* @dev: Device to add the callbacks to. -* @ops: Set of callbacks to add. -* @td: Timing data to add to the device along with the callbacks (optional). -* -* Every call to this routine should be balanced with a call to -* __pm_genpd_remove_callbacks() and they must not be nested. -*/ -int pm_genpd_add_callbacks (struct device *dev,struct gpd_dev_ops *ops, -struct gpd_timing_data *td) -{ -struct generic_pm_domain_data *gpd_data_new, *gpd_data =NULL ; -int ret =0 ; - -if (!(dev && ops)) -return -EINVAL ; - - gpd_data_new =__pm_genpd_alloc_dev_data (dev); -if (!gpd_data_new) -return -ENOMEM ; - -pm_runtime_disable (dev); -device_pm_lock (); - - ret =dev_pm_get_subsys_data (dev); -if (ret) - goto out; - -spin_lock_irq (&dev->power.lock); - -if (dev->power.subsys_data->domain_data) { - gpd_data =to_gpd_data (dev->power.subsys_data->domain_data); - }else { - gpd_data = gpd_data_new; - dev->power.subsys_data->domain_data = &gpd_data->base; - } - gpd_data->refcount++; - gpd_data->ops = *ops; -if (td) - gpd_data->td = *td; - -spin_unlock_irq (&dev->power.lock); - - out: -device_pm_unlock (); -pm_runtime_enable (dev); - -if (gpd_data != gpd_data_new) -__pm_genpd_free_dev_data (dev, gpd_data_new); - -return ret; -} -EXPORT_SYMBOL_GPL (pm_genpd_add_callbacks); - -/** -* __pm_genpd_remove_callbacks - Remove PM domain callbacks from a given device. -* @dev: Device to remove the callbacks from. -* @clear_td: If set, clear the device's timing data too. -* -* This routine can only be called after pm_genpd_add_callbacks(). -*/ -int __pm_genpd_remove_callbacks (struct device *dev,bool clear_td) -{ -struct generic_pm_domain_data *gpd_data =NULL ; -bool remove = false; -int ret =0 ; - -if (!(dev && dev->power.subsys_data)) -return -EINVAL ; - -pm_runtime_disable (dev); -device_pm_lock (); - -spin_lock_irq (&dev->power.lock); - -if (dev->power.subsys_data->domain_data) { - gpd_data =to_gpd_data (dev->power.subsys_data->domain_data); - gpd_data->ops = (struct gpd_dev_ops ){NULL }; -if (clear_td) - gpd_data->td = (struct gpd_timing_data ){0 }; - -if (--gpd_data->refcount ==0 ) { - dev->power.subsys_data->domain_data =NULL ; - remove = true; - } - }else { - ret = -EINVAL ; - } - -spin_unlock_irq (&dev->power.lock); - -device_pm_unlock (); -pm_runtime_enable (dev); - -if (ret) -return ret; - -dev_pm_put_subsys_data (dev); -if (remove) -__pm_genpd_free_dev_data (dev, gpd_data); - -return 0 ; -} -EXPORT_SYMBOL_GPL (__pm_genpd_remove_callbacks); - -/** * pm_genpd_attach_cpuidle - Connect the given PM domain with cpuidle. * @genpd: PM domain to be connected with cpuidle. * @state: cpuidle state this domain can disable/enable.
include/linux/pm_domain.h +0 -20
@@ -108,7 +108,6 @@ struct gpd_timing_data {struct generic_pm_domain_data {struct pm_domain_data base; -struct gpd_dev_ops ops;struct gpd_timing_data td;struct notifier_block nb;struct mutex lock;
@@ -151,10 +150,6 @@ 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, -struct gpd_dev_ops *ops, -struct gpd_timing_data *td); -extern int __pm_genpd_remove_callbacks (struct device *dev,bool clear_td);extern int pm_genpd_attach_cpuidle (struct generic_pm_domain *genpd,int state);extern int pm_genpd_name_attach_cpuidle (const char *name,int state);extern int pm_genpd_detach_cpuidle (struct generic_pm_domain *genpd);
@@ -217,16 +212,6 @@ static inline int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd, {return -ENOSYS ; } -static inline int pm_genpd_add_callbacks (struct device *dev, -struct gpd_dev_ops *ops, -struct gpd_timing_data *td) -{ -return -ENOSYS ; -} -static inline int __pm_genpd_remove_callbacks (struct device *dev,bool clear_td) -{ -return -ENOSYS ; -}static inline int pm_genpd_attach_cpuidle (struct generic_pm_domain *genpd,int st) {return -ENOSYS ;
@@ -281,11 +266,6 @@ static inline int pm_genpd_name_add_device(const char *domain_name,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); -} -#ifdef CONFIG_PM_GENERIC_DOMAINS_RUNTIME extern void genpd_queue_power_off_work (struct generic_pm_domain *genpd);extern void pm_genpd_poweroff_unused (void );
Signature · 1 line
1.7.9.5
PATCH 6/24 PM / Domains: Remove system PM callbacks from gpd_dev_ops
In reply to Ulf HanssonThere no users of these callbacks, let's simplify the generic power domain by removing them.
--- drivers/base/power/domain.c | 64 ++++++------------------------------------- include/linux/pm_domain.h | 8 ------ 2 files changed, 8 insertions(+), 64 deletions(-)
drivers/base/power/domain.c +8 -56
@@ -771,46 +771,6 @@ static bool genpd_dev_active_wakeup(struct generic_pm_domain *genpd,return GENPD_DEV_CALLBACK (genpd, bool, active_wakeup, dev); } -static int genpd_suspend_dev (struct generic_pm_domain *genpd,struct device *dev) -{ -return GENPD_DEV_CALLBACK (genpd, int, suspend, dev); -} - -static int genpd_suspend_late (struct generic_pm_domain *genpd,struct device *dev) -{ -return GENPD_DEV_CALLBACK (genpd, int, suspend_late, dev); -} - -static int genpd_resume_early (struct generic_pm_domain *genpd,struct device *dev) -{ -return GENPD_DEV_CALLBACK (genpd, int, resume_early, dev); -} - -static int genpd_resume_dev (struct generic_pm_domain *genpd,struct device *dev) -{ -return GENPD_DEV_CALLBACK (genpd, int, resume, dev); -} - -static int genpd_freeze_dev (struct generic_pm_domain *genpd,struct device *dev) -{ -return GENPD_DEV_CALLBACK (genpd, int, freeze, dev); -} - -static int genpd_freeze_late (struct generic_pm_domain *genpd,struct device *dev) -{ -return GENPD_DEV_CALLBACK (genpd, int, freeze_late, dev); -} - -static int genpd_thaw_early (struct generic_pm_domain *genpd,struct device *dev) -{ -return GENPD_DEV_CALLBACK (genpd, int, thaw_early, dev); -} - -static int genpd_thaw_dev (struct generic_pm_domain *genpd,struct device *dev) -{ -return GENPD_DEV_CALLBACK (genpd, int, thaw, dev); -} -/** * pm_genpd_sync_poweroff - Synchronously power off a PM domain and its masters. * @genpd: PM domain to power off, if possible.
@@ -992,7 +952,7 @@ static int pm_genpd_suspend(struct device *dev)if (IS_ERR (genpd))return -EINVAL ; -return genpd->suspend_power_off ?0 :genpd_suspend_dev (genpd, dev); +return genpd->suspend_power_off ?0 :pm_generic_suspend (dev); }/**
@@ -1013,7 +973,7 @@ static int pm_genpd_suspend_late(struct device *dev)if (IS_ERR (genpd))return -EINVAL ; -return genpd->suspend_power_off ?0 :genpd_suspend_late (genpd, dev); +return genpd->suspend_power_off ?0 :pm_generic_suspend_late (dev); }/**
@@ -1100,7 +1060,7 @@ static int pm_genpd_resume_early(struct device *dev)if (IS_ERR (genpd))return -EINVAL ; -return genpd->suspend_power_off ?0 :genpd_resume_early (genpd, dev); +return genpd->suspend_power_off ?0 :pm_generic_resume_early (dev); }/**
@@ -1121,7 +1081,7 @@ static int pm_genpd_resume(struct device *dev)if (IS_ERR (genpd))return -EINVAL ; -return genpd->suspend_power_off ?0 :genpd_resume_dev (genpd, dev); +return genpd->suspend_power_off ?0 :pm_generic_resume (dev); }/**
@@ -1142,7 +1102,7 @@ static int pm_genpd_freeze(struct device *dev)if (IS_ERR (genpd))return -EINVAL ; -return genpd->suspend_power_off ?0 :genpd_freeze_dev (genpd, dev); +return genpd->suspend_power_off ?0 :pm_generic_freeze (dev); }/**
@@ -1164,7 +1124,7 @@ static int pm_genpd_freeze_late(struct device *dev)if (IS_ERR (genpd))return -EINVAL ; -return genpd->suspend_power_off ?0 :genpd_freeze_late (genpd, dev); +return genpd->suspend_power_off ?0 :pm_generic_freeze_late (dev); }/**
@@ -1228,7 +1188,7 @@ static int pm_genpd_thaw_early(struct device *dev)if (IS_ERR (genpd))return -EINVAL ; -return genpd->suspend_power_off ?0 :genpd_thaw_early (genpd, dev); +return genpd->suspend_power_off ?0 :pm_generic_thaw_early (dev); }/**
@@ -1249,7 +1209,7 @@ static int pm_genpd_thaw(struct device *dev)if (IS_ERR (genpd))return -EINVAL ; -return genpd->suspend_power_off ?0 :genpd_thaw_dev (genpd, dev); +return genpd->suspend_power_off ?0 :pm_generic_thaw (dev); }/**
@@ -1957,14 +1917,6 @@ void pm_genpd_init(struct generic_pm_domain *genpd, genpd->domain.ops.complete = pm_genpd_complete; genpd->dev_ops.save_state = pm_genpd_default_save_state; genpd->dev_ops.restore_state = pm_genpd_default_restore_state; - genpd->dev_ops.suspend = pm_generic_suspend; - genpd->dev_ops.suspend_late = pm_generic_suspend_late; - genpd->dev_ops.resume_early = pm_generic_resume_early; - genpd->dev_ops.resume = pm_generic_resume; - genpd->dev_ops.freeze = pm_generic_freeze; - genpd->dev_ops.freeze_late = pm_generic_freeze_late; - genpd->dev_ops.thaw_early = pm_generic_thaw_early; - genpd->dev_ops.thaw = pm_generic_thaw;mutex_lock (&gpd_list_lock);list_add (&genpd->gpd_list_node, &gpd_list);mutex_unlock (&gpd_list_lock);
include/linux/pm_domain.h +0 -8
@@ -35,14 +35,6 @@ struct gpd_dev_ops {int (*stop)(struct device *dev);int (*save_state)(struct device *dev);int (*restore_state)(struct device *dev); -int (*suspend)(struct device *dev); -int (*suspend_late)(struct device *dev); -int (*resume_early)(struct device *dev); -int (*resume)(struct device *dev); -int (*freeze)(struct device *dev); -int (*freeze_late)(struct device *dev); -int (*thaw_early)(struct device *dev); -int (*thaw)(struct device *dev);bool (*active_wakeup)(struct device *dev); };
Signature · 1 line
1.7.9.5
PATCH 7/24 ARM: shmobile: Drop dev_irq_safe from r8a7779 genpd config
In reply to Ulf HanssonThe dev_irq_safe configuration is redundant, genpd don't have any special treatmeant for handling it. Let's remove it.
--- arch/arm/mach-shmobile/pm-r8a7779.c | 1 - 1 file changed, 1 deletion(-)
arch/arm/mach-shmobile/pm-r8a7779.c +0 -1
@@ -74,7 +74,6 @@ static void r8a7779_init_pm_domain(struct r8a7779_pm_domain *r8a7779_pd) genpd->dev_ops.stop = pm_clk_suspend; genpd->dev_ops.start = pm_clk_resume; genpd->dev_ops.active_wakeup = pd_active_wakeup; - genpd->dev_irq_safe = true; genpd->power_off = pd_power_down; genpd->power_on = pd_power_up;
Signature · 1 line
1.7.9.5
PATCH 7/24 ARM: shmobile: Drop dev_irq_safe from r8a7779 genpd config
Quoted 2 lines · Ulf Hansson
The
dev_irq_safeconfiguration is redundant, genpd don't have any special treatmeant for handling it. Let's remove it.
Why?
The genpd core needs to handle irq_safe properly eventully (right now it just doesn't call power_off/power_on callbacks, but that needs to be implmenented. c.f commit 0aa2a22169)
If we remove these flags from platforms, we're taking away information that the platform maintainers have specified tha will be useful when full support is avialble.
Kevin
PATCH 7/24 ARM: shmobile: Drop dev_irq_safe from r8a7779 genpd config
Quoted 7 lines · Kevin Hilman
Quoted 2 lines · Ulf Hansson
The
dev_irq_safeconfiguration is redundant, genpd don't have any special treatmeant for handling it. Let's remove it.Why?
Quoted 7 lines
The genpd core needs to handle
irq_safeproperly eventully (right now it just doesn't call power_off/power_on callbacks, but that needs to be implmenented. c.f commit0aa2a22169)If we remove these flags from platforms, we're taking away information that the platform maintainers have specified tha will be useful when full support is avialble.
For sure this is needed in _some_ form. But before we even figured out how to support irq_safe genpd's, why even bother to support a configuration for it?
Currently I think it good enough to use the per device irq_safe option, and then let's see how handling of these devices evolves.
Kind regards
Uffe
PATCH 8/24 ARM: shmobile: Drop dev_irq_safe from R-mobile genpd config
In reply to Ulf HanssonThe dev_irq_safe configuration is redundant, genpd don't have any special treatmeant for handling it. Let's remove it.
--- arch/arm/mach-shmobile/pm-rmobile.c | 1 - 1 file changed, 1 deletion(-)
arch/arm/mach-shmobile/pm-rmobile.c +0 -1
@@ -111,7 +111,6 @@ static void rmobile_init_pm_domain(struct rmobile_pm_domain *rmobile_pd) genpd->dev_ops.stop = pm_clk_suspend; genpd->dev_ops.start = pm_clk_resume; genpd->dev_ops.active_wakeup = rmobile_pd_active_wakeup; - genpd->dev_irq_safe = true; genpd->power_off = rmobile_pd_power_down; genpd->power_on = rmobile_pd_power_up;__rmobile_pd_power_up (rmobile_pd, false);
Signature · 1 line
1.7.9.5
PATCH 9/24 PM / Domains: Remove dev_irq_safe from genpd config
In reply to Ulf HanssonThe genpd dev_irq_safe configuration overlaps with the runtime PM pm_runtime_irq_safe() option. Let's remove it.
--- drivers/base/power/domain.c | 4 ---- include/linux/pm_domain.h | 1 - 2 files changed, 5 deletions(-)
drivers/base/power/domain.c +0 -4
@@ -616,8 +616,6 @@ static int pm_genpd_runtime_suspend(struct device *dev)if (IS_ERR (genpd))return -EINVAL ; -might_sleep_if (!genpd->dev_irq_safe); - stop_ok = genpd->gov ? genpd->gov->stop_ok :NULL ;if (stop_ok && !stop_ok (dev))return -EBUSY ;
@@ -662,8 +660,6 @@ static int pm_genpd_runtime_resume(struct device *dev)if (IS_ERR (genpd))return -EINVAL ; -might_sleep_if (!genpd->dev_irq_safe); -/* If power.irq_safe, the PM domain is never powered off. */ if (dev->power.irq_safe)return genpd_start_dev_no_timing (genpd, dev);
include/linux/pm_domain.h +0 -1
@@ -63,7 +63,6 @@ struct generic_pm_domain {unsigned int suspended_count;/* System suspend device counter */ unsigned int prepared_count;/* Suspend counter of prepared devices */ bool suspend_power_off;/* Power status before system suspend */ -bool dev_irq_safe;/* Device callbacks are IRQ-safe */ int (*power_off)(struct generic_pm_domain *domain);s64 power_off_latency_ns;int (*power_on)(struct generic_pm_domain *domain);
Signature · 1 line
1.7.9.5
PATCH 10/24 PM / Domains: Remove redundant check for CONFIG_PM
In reply to Ulf HanssonCONFIG_PM_GENERIC_DOMAINS depends on CONFIG_PM, thus there are no need to check explicity for it.
--- drivers/base/power/domain.c | 4 ---- 1 file changed, 4 deletions(-)
drivers/base/power/domain.c +0 -4
@@ -67,8 +67,6 @@ static struct generic_pm_domain *pm_genpd_lookup_name(const char *domain_name)return genpd; } -#ifdef CONFIG_PM -struct generic_pm_domain *dev_to_genpd (struct device *dev) {if (IS_ERR_OR_NULL (dev->pm_domain))
@@ -282,8 +280,6 @@ int pm_genpd_name_poweron(const char *domain_name)return genpd ?pm_genpd_poweron (genpd) : -EINVAL ; } -#endif /* CONFIG_PM */ -#ifdef CONFIG_PM_RUNTIME static int genpd_start_dev_no_timing(struct generic_pm_domain *genpd,
Signature · 1 line
1.7.9.5
PATCH 11/24 PM / Domains: Remove legacy API for adding devices through DT
In reply to Ulf HanssonThere are no active clients of the legacy API and we now also have a sophisticated way, where driver core deals with adding devices to genpd while probing. So, let's remove the legacy API.
--- drivers/base/power/domain.c | 33 --------------------------------- include/linux/pm_domain.h | 17 ----------------- 2 files changed, 50 deletions(-)
drivers/base/power/domain.c +0 -33
@@ -1433,39 +1433,6 @@ int __pm_genpd_add_device(struct generic_pm_domain *genpd, struct device *dev, }/** -* __pm_genpd_of_add_device - Add a device to an I/O PM domain. -* @genpd_node: Device tree node pointer representing a PM domain to which the -* the device is added to. -* @dev: Device to be added. -* @td: Set of PM QoS timing parameters to attach to the device. -*/ -int __pm_genpd_of_add_device (struct device_node *genpd_node,struct device *dev, -struct gpd_timing_data *td) -{ -struct generic_pm_domain *genpd =NULL , *gpd; - -dev_dbg (dev,"%s()\n" , __func__); - -if (IS_ERR_OR_NULL (genpd_node) ||IS_ERR_OR_NULL (dev)) -return -EINVAL ; - -mutex_lock (&gpd_list_lock); -list_for_each_entry (gpd, &gpd_list, gpd_list_node) { -if (gpd->of_node == genpd_node) { - genpd = gpd; -break ; - } - } -mutex_unlock (&gpd_list_lock); - -if (!genpd) -return -EINVAL ; - -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.
include/linux/pm_domain.h +0 -17
@@ -71,7 +71,6 @@ struct generic_pm_domain {s64 max_off_time_ns;/* Maximum allowed "suspended" time. */ bool max_off_time_changed;bool cached_power_down_ok; -struct device_node *of_node;/* Node in device tree */ struct gpd_cpu_data *cpu_data; };
@@ -124,10 +123,6 @@ extern int __pm_genpd_add_device(struct generic_pm_domain *genpd,struct device *dev, struct gpd_timing_data *td); -extern int __pm_genpd_of_add_device (struct device_node *genpd_node, -struct device *dev, -struct gpd_timing_data *td); -extern int __pm_genpd_name_add_device (const char *domain_name,struct device *dev,struct gpd_timing_data *td);
@@ -170,12 +165,6 @@ static inline int __pm_genpd_add_device(struct generic_pm_domain *genpd, {return -ENOSYS ; } -static inline int __pm_genpd_of_add_device (struct device_node *genpd_node, -struct device *dev, -struct gpd_timing_data *td) -{ -return -ENOSYS ; -}static inline int __pm_genpd_name_add_device (const char *domain_name,struct device *dev,struct gpd_timing_data *td)
@@ -245,12 +234,6 @@ static inline int pm_genpd_add_device(struct generic_pm_domain *genpd,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) {
Signature · 1 line
1.7.9.5
PATCH 12/24 PM / Domains: Remove pm_genpd_syscore_switch() API
In reply to Ulf HanssonThe pm_genpd_syscore_poweroff() API and pm_genpd_syscore_poweron() API makes the pm_genpd_syscore_switch() API redundant.
Moreover, since there are no active users, let's just remove it.
--- drivers/base/power/domain.c | 17 ++++++++++++++--- include/linux/pm_domain.h | 16 ++++------------ 2 files changed, 18 insertions(+), 15 deletions(-)
drivers/base/power/domain.c +14 -3
@@ -1293,13 +1293,13 @@ static void pm_genpd_complete(struct device *dev) }/** -* pm_genpd_syscore_switch - Switch power during system core suspend or resume. +* genpd_syscore_switch - Switch power during system core suspend or resume. * @dev: Device that normally is marked as "always on" to switch power for. * * This routine may only be called during the system core (syscore) suspend or * resume phase for devices whose "always on" flags are set. */ -void pm_genpd_syscore_switch (struct device *dev,bool suspend) +static void genpd_syscore_switch (struct device *dev,bool suspend) {struct generic_pm_domain *genpd;
@@ -1315,7 +1315,18 @@ void pm_genpd_syscore_switch(struct device *dev, bool suspend) genpd->suspended_count--; } } -EXPORT_SYMBOL_GPL (pm_genpd_syscore_switch); + +void pm_genpd_syscore_poweroff (struct device *dev) +{ +genpd_syscore_switch (dev, true); +} +EXPORT_SYMBOL_GPL (pm_genpd_syscore_poweroff); + +void pm_genpd_syscore_poweron (struct device *dev) +{ +genpd_syscore_switch (dev, false); +} +EXPORT_SYMBOL_GPL (pm_genpd_syscore_poweron);#else
include/linux/pm_domain.h +4 -12
@@ -249,21 +249,13 @@ static inline void pm_genpd_poweroff_unused(void) {}#endif #ifdef CONFIG_PM_GENERIC_DOMAINS_SLEEP -extern void pm_genpd_syscore_switch (struct device *dev,bool suspend); +extern void pm_genpd_syscore_poweroff (struct device *dev); +extern void pm_genpd_syscore_poweron (struct device *dev);#else -static inline void pm_genpd_syscore_switch (struct device *dev,bool suspend) {} +static inline void pm_genpd_syscore_poweroff (struct device *dev) {} +static inline void pm_genpd_syscore_poweron (struct device *dev) {}#endif -static inline void pm_genpd_syscore_poweroff (struct device *dev) -{ -pm_genpd_syscore_switch (dev, true); -} - -static inline void pm_genpd_syscore_poweron (struct device *dev) -{ -pm_genpd_syscore_switch (dev, false); -} -/* OF power domain providers */ struct of_device_id ;
Signature · 1 line
1.7.9.5
PATCH 13/24 PM / Domains: Remove genpd_queue_power_off_work() API
In reply to Ulf HanssonThere are no active users of this API. Let's remove it and if future needs shows up which could consider to have a get/put API instead.
--- drivers/base/power/domain.c | 5 ++++- include/linux/pm_domain.h | 2 -- 2 files changed, 4 insertions(+), 3 deletions(-)
drivers/base/power/domain.c +4 -1
@@ -423,7 +423,7 @@ static bool genpd_abort_poweroff(struct generic_pm_domain *genpd)* Queue up the execution of pm_genpd_poweroff() unless it's already been done * before. */ -void genpd_queue_power_off_work (struct generic_pm_domain *genpd) +static void genpd_queue_power_off_work (struct generic_pm_domain *genpd) {queue_work (pm_wq, &genpd->power_off_work); }
@@ -730,6 +730,9 @@ static inline int genpd_dev_pm_qos_notifier(struct notifier_block *nb,return NOTIFY_DONE ; } +static inline void +genpd_queue_power_off_work (struct generic_pm_domain *genpd) {} +static inline void genpd_power_off_work_fn (struct work_struct *work) {}#define pm_genpd_runtime_suspend NULL
include/linux/pm_domain.h +0 -2
@@ -241,10 +241,8 @@ static inline int pm_genpd_name_add_device(const char *domain_name, }#ifdef CONFIG_PM_GENERIC_DOMAINS_RUNTIME -extern void genpd_queue_power_off_work (struct generic_pm_domain *genpd);extern void pm_genpd_poweroff_unused (void );#else -static inline void genpd_queue_power_off_work (struct generic_pm_domain *gpd) {}static inline void pm_genpd_poweroff_unused (void ) {}#endif
Signature · 1 line
1.7.9.5
PATCH 14/24 PM / Domains: Add late_initcall to disable unused domains
In reply to Ulf HanssonAs default behavior let genpd at late init try to disable the unused domains.
--- drivers/base/power/domain.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/base/power/domain.c +7 -0
@@ -722,6 +722,13 @@ void pm_genpd_poweroff_unused(void)mutex_unlock (&gpd_list_lock); } +static int __init genpd_poweroff_unused (void ) +{ +pm_genpd_poweroff_unused (); +return 0 ; +} +late_initcall (genpd_poweroff_unused); +#else static inline int genpd_dev_pm_qos_notifier(struct notifier_block *nb,
Signature · 1 line
1.7.9.5
PATCH 15/24 ARM: exynos: Leave disabling of unused pm domains to genpd
In reply to Ulf HanssonSince genpd at late init, will try to disable unused domains we don't need to handle it from here as well.
--- arch/arm/mach-exynos/exynos.c | 1 - 1 file changed, 1 deletion(-)
arch/arm/mach-exynos/exynos.c +0 -1
@@ -193,7 +193,6 @@ void __init exynos_init_late(void)/* to be supported later */ return ; -pm_genpd_poweroff_unused ();exynos_pm_init (); }
Signature · 1 line
1.7.9.5
PATCH 16/24 ARM: s3c64xx: Leave disabling of unused pm domains to genpd
In reply to Ulf HanssonSince genpd at late init, will try to disable unused domains we don't need to handle it from machine specific code as well.
--- arch/arm/mach-s3c64xx/common.c | 5 ----- arch/arm/mach-s3c64xx/common.h | 7 ------- arch/arm/mach-s3c64xx/mach-anw6410.c | 1 - arch/arm/mach-s3c64xx/mach-crag6410.c | 1 - arch/arm/mach-s3c64xx/mach-hmt.c | 1 - arch/arm/mach-s3c64xx/mach-mini6410.c | 1 - arch/arm/mach-s3c64xx/mach-ncp.c | 1 - arch/arm/mach-s3c64xx/mach-real6410.c | 1 - arch/arm/mach-s3c64xx/mach-smartq5.c | 1 - arch/arm/mach-s3c64xx/mach-smartq7.c | 1 - arch/arm/mach-s3c64xx/mach-smdk6400.c | 1 - arch/arm/mach-s3c64xx/mach-smdk6410.c | 1 - arch/arm/mach-s3c64xx/pm.c | 7 ------- 13 files changed, 29 deletions(-)
arch/arm/mach-s3c64xx/common.c +0 -5
@@ -440,8 +440,3 @@ void s3c64xx_restart(enum reboot_mode mode, const char *cmd)/* if all else fails, or mode was for soft, jump to 0 */ soft_restart (0 ); } - -void __init s3c64xx_init_late (void ) -{ -s3c64xx_pm_late_initcall (); -}
arch/arm/mach-s3c64xx/common.h +0 -7
@@ -23,7 +23,6 @@ void s3c64xx_init_irq(u32 vic0, u32 vic1);void s3c64xx_init_io (struct map_desc *mach_desc,int size);void s3c64xx_restart (enum reboot_mode mode,const char *cmd); -void s3c64xx_init_late (void );void s3c64xx_clk_init (struct device_node *np,unsigned long xtal_f,unsigned long xusbxti_f,bool is_s3c6400,void __iomem *reg_base);
@@ -52,12 +51,6 @@ extern void s3c6410_map_io(void);#define s3c6410_init NULL#endif -#ifdef CONFIG_PM -int __init s3c64xx_pm_late_initcall (void ); -#else -static inline int s3c64xx_pm_late_initcall (void ) {return 0 ; } -#endif -#ifdef CONFIG_S3C64XX_PL080 extern struct pl08x_platform_data s3c64xx_dma0_plat_data;extern struct pl08x_platform_data s3c64xx_dma1_plat_data;
arch/arm/mach-s3c64xx/mach-anw6410.c +0 -1
@@ -234,7 +234,6 @@ MACHINE_START(ANW6410, "A&W6410") .init_irq = s3c6410_init_irq, .map_io = anw6410_map_io, .init_machine = anw6410_machine_init, - .init_late = s3c64xx_init_late, .init_time = samsung_timer_init, .restart = s3c64xx_restart,MACHINE_END
arch/arm/mach-s3c64xx/mach-crag6410.c +0 -1
@@ -858,7 +858,6 @@ MACHINE_START(WLF_CRAGG_6410, "Wolfson Cragganmore 6410") .init_irq = s3c6410_init_irq, .map_io = crag6410_map_io, .init_machine = crag6410_machine_init, - .init_late = s3c64xx_init_late, .init_time = samsung_timer_init, .restart = s3c64xx_restart,MACHINE_END
arch/arm/mach-s3c64xx/mach-hmt.c +0 -1
@@ -278,7 +278,6 @@ MACHINE_START(HMT, "Airgoo-HMT") .init_irq = s3c6410_init_irq, .map_io = hmt_map_io, .init_machine = hmt_machine_init, - .init_late = s3c64xx_init_late, .init_time = samsung_timer_init, .restart = s3c64xx_restart,MACHINE_END
arch/arm/mach-s3c64xx/mach-mini6410.c +0 -1
@@ -366,7 +366,6 @@ MACHINE_START(MINI6410, "MINI6410") .init_irq = s3c6410_init_irq, .map_io = mini6410_map_io, .init_machine = mini6410_machine_init, - .init_late = s3c64xx_init_late, .init_time = samsung_timer_init, .restart = s3c64xx_restart,MACHINE_END
arch/arm/mach-s3c64xx/mach-ncp.c +0 -1
@@ -104,7 +104,6 @@ MACHINE_START(NCP, "NCP") .init_irq = s3c6410_init_irq, .map_io = ncp_map_io, .init_machine = ncp_machine_init, - .init_late = s3c64xx_init_late, .init_time = samsung_timer_init, .restart = s3c64xx_restart,MACHINE_END
arch/arm/mach-s3c64xx/mach-real6410.c +0 -1
@@ -335,7 +335,6 @@ MACHINE_START(REAL6410, "REAL6410") .init_irq = s3c6410_init_irq, .map_io = real6410_map_io, .init_machine = real6410_machine_init, - .init_late = s3c64xx_init_late, .init_time = samsung_timer_init, .restart = s3c64xx_restart,MACHINE_END
arch/arm/mach-s3c64xx/mach-smartq5.c +0 -1
@@ -156,7 +156,6 @@ MACHINE_START(SMARTQ5, "SmartQ 5") .init_irq = s3c6410_init_irq, .map_io = smartq_map_io, .init_machine = smartq5_machine_init, - .init_late = s3c64xx_init_late, .init_time = samsung_timer_init, .restart = s3c64xx_restart,MACHINE_END
arch/arm/mach-s3c64xx/mach-smartq7.c +0 -1
@@ -172,7 +172,6 @@ MACHINE_START(SMARTQ7, "SmartQ 7") .init_irq = s3c6410_init_irq, .map_io = smartq_map_io, .init_machine = smartq7_machine_init, - .init_late = s3c64xx_init_late, .init_time = samsung_timer_init, .restart = s3c64xx_restart,MACHINE_END
arch/arm/mach-s3c64xx/mach-smdk6400.c +0 -1
@@ -93,7 +93,6 @@ MACHINE_START(SMDK6400, "SMDK6400") .init_irq = s3c6400_init_irq, .map_io = smdk6400_map_io, .init_machine = smdk6400_machine_init, - .init_late = s3c64xx_init_late, .init_time = samsung_timer_init, .restart = s3c64xx_restart,MACHINE_END
arch/arm/mach-s3c64xx/mach-smdk6410.c +0 -1
@@ -706,7 +706,6 @@ MACHINE_START(SMDK6410, "SMDK6410") .init_irq = s3c6410_init_irq, .map_io = smdk6410_map_io, .init_machine = smdk6410_machine_init, - .init_late = s3c64xx_init_late, .init_time = samsung_timer_init, .restart = s3c64xx_restart,MACHINE_END
arch/arm/mach-s3c64xx/pm.c +0 -7
@@ -347,10 +347,3 @@ static __init int s3c64xx_pm_initcall(void)return 0 ; }arch_initcall (s3c64xx_pm_initcall); - -int __init s3c64xx_pm_late_initcall (void ) -{ -pm_genpd_poweroff_unused (); - -return 0 ; -}
Signature · 1 line
1.7.9.5
PATCH 17/24 drivers: sh: Leave disabling of unused pm domains to genpd
In reply to Ulf HanssonSince genpd at late init, will try to disable unused domains we don't need to handle it from here as well.
--- drivers/sh/pm_runtime.c | 11 ----------- 1 file changed, 11 deletions(-)
drivers/sh/pm_runtime.c +0 -11
@@ -50,8 +50,6 @@ static struct pm_clk_notifier_block platform_bus_notifier = { .con_ids = { NULL, }, }; -static bool default_pm_on; -static int __init sh_pm_runtime_init (void ) {if (IS_ENABLED (CONFIG_ARCH_SHMOBILE_MULTI )) {
@@ -68,16 +66,7 @@ static int __init sh_pm_runtime_init(void)return 0 ; } - default_pm_on = true;pm_clk_add_notifier (&platform_bus_type, &platform_bus_notifier);return 0 ; }core_initcall (sh_pm_runtime_init); - -static int __init sh_pm_runtime_late_init (void ) -{ -if (default_pm_on) -pm_genpd_poweroff_unused (); -return 0 ; -} -late_initcall (sh_pm_runtime_late_init);
Signature · 1 line
1.7.9.5
PATCH 18/24 PM / Domains: Remove default_stop_ok() API
In reply to Ulf HanssonThere are currently no need to export default_stop_ok() as an API, instead let's keep it local to the domain governor.
--- drivers/base/power/domain_governor.c | 7 ++----- include/linux/pm_domain.h | 9 +-------- 2 files changed, 3 insertions(+), 13 deletions(-)
drivers/base/power/domain_governor.c +2 -5
@@ -42,7 +42,7 @@ static int dev_update_qos_constraint(struct device *dev, void *data)* default_stop_ok - Default PM domain governor routine for stopping devices. * @dev: Device to check. */ -bool default_stop_ok (struct device *dev) +static bool default_stop_ok (struct device *dev) {struct gpd_timing_data *td = &dev_gpd_data (dev)->td;unsigned long flags;
@@ -229,10 +229,7 @@ static bool always_on_power_down_ok(struct dev_pm_domain *domain)#else /* !CONFIG_PM_RUNTIME */ -bool default_stop_ok (struct device *dev) -{ -return false; -} +static inline bool default_stop_ok (struct device *dev) {return false; }#define default_power_down_ok NULL#define always_on_power_down_ok NULL
include/linux/pm_domain.h +1 -8
@@ -116,8 +116,6 @@ static inline struct generic_pm_domain_data *dev_gpd_data(struct device *dev)return to_gpd_data (dev->power.subsys_data->domain_data); } -extern struct dev_power_governor simple_qos_governor; -extern struct generic_pm_domain *dev_to_genpd (struct device *dev); extern int __pm_genpd_add_device(struct generic_pm_domain *genpd, struct device *dev,
@@ -146,8 +144,7 @@ extern void pm_genpd_init(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); -extern bool default_stop_ok (struct device *dev); - +extern struct dev_power_governor simple_qos_governor;extern struct dev_power_governor pm_domain_always_on_gov;#else
@@ -220,10 +217,6 @@ static inline int pm_genpd_name_poweron(const char *domain_name) {return -ENOSYS ; } -static inline bool default_stop_ok (struct device *dev) -{ -return false; -}#define simple_qos_governor NULL#define pm_domain_always_on_gov NULL#endif
Signature · 1 line
1.7.9.5
PATCH 19/24 dt: bindings: ux500: Add documentation for power domains
In reply to Ulf Hansson--- .../devicetree/bindings/arm/ux500/power_domain.txt | 35 ++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/ux500/power_domain.txt
Documentation/devicetree/bindings/arm/ux500/power_domain.txt new file +35 -0
@@ -0,0 +1,35 @@ +* ST-Ericsson UX500 Power Domains + +UX500 supports multiple power domains which are used to gate power to one or +more peripherals on the SOC. + +The implementation of power domains for UX500 are based upon the generic power +domain and use the corresponding DT bindings. + +==Power domain providers== + +Required properties: + - compatible: Must be "stericsson,ux500-pm-domains". + - #power-domain-cells : Number of cells in a power domain specifier, must be 1. + +Example: + pm_domains: pm_domains0 { + compatible = "stericsson,ux500-pm-domains"; + #power-domain-cells = <1>; + }; + +==Power domain consumers== + +Required properties: + - power-domains: A phandle and power domain specifier. Below are the list of + valid specifiers: + + Index Specifier + ----- --------- + 0 DOMAIN_VAPE + +Example: + sdi0_per1 at 80126000 { + compatible = "arm,pl18x", "arm,primecell"; + power-domains = <&pm_domains DOMAIN_VAPE> + };
Signature · 1 line
1.7.9.5
PATCH 19/24 dt: bindings: ux500: Add documentation for power domains
Ulf Hansson <[email protected]> writes:
-EMISSING_CHANGELOG
Quoted 4 lines
Cc Linus Walleij <[email protected]>Cc Tomasz Figa <[email protected]>Cc devicetree at vger.kernel.orgSigned-off-by Ulf Hansson <[email protected]>
PATCH 19/24 dt: bindings: ux500: Add documentation for power domains
Quoted 3 lines · Kevin Hilman
Ulf Hansson <[email protected]> writes:
-EMISSING_CHANGELOG
-EBAD_REVIEW
Subject says it all, it adds documentation, what more would you like to see in the changelog?
Lets not make patch submission harder than it needs to be...
Pavel
Quoted 4 lines
Quoted 4 lines
Cc Linus Walleij <[email protected]>Cc Tomasz Figa <[email protected]>Cc devicetree at vger.kernel.orgSigned-off-by Ulf Hansson <[email protected]>
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
PATCH 20/24 dt: bindings: ux500: Add header for power domains specifiers
In reply to Ulf Hansson--- include/dt-bindings/arm/ux500_pm_domains.h | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 include/dt-bindings/arm/ux500_pm_domains.h
include/dt-bindings/arm/ux500_pm_domains.h new file +15 -0
@@ -0,0 +1,15 @@ +/* +* Copyright (C) 2014 Linaro Ltd. +* +* Author: Ulf Hansson <[email protected]> +* License terms: GNU General Public License (GPL) version 2 +*/ +#ifndef _DT_BINDINGS_ARM_UX500_PM_DOMAINS_H +#define _DT_BINDINGS_ARM_UX500_PM_DOMAINS_H + +#define DOMAIN_VAPE 0 + +/* Number of power domains. */ +#define NR_DOMAINS (DOMAIN_VAPE + 1) + +#endif
Signature · 1 line
1.7.9.5
PATCH 20/24 dt: bindings: ux500: Add header for power domains specifiers
Ulf Hansson <[email protected]> writes:
-EMISSING_CHANGELOG
Quoted 4 lines
Cc Linus Walleij <[email protected]>Cc Tomasz Figa <[email protected]>Cc devicetree at vger.kernel.orgSigned-off-by Ulf Hansson <[email protected]>
PATCH 21/24 ARM: ux500: Initial support for power domains
In reply to Ulf HanssonThe ux500 SoC uses the generic power domain and requires the domains to be specified through DT.
Currently the callbacks for handling power gating are empty functions which shall be implemented once each device are handled properly from a runtime PM perspective.
--- arch/arm/mach-ux500/Makefile | 1 + arch/arm/mach-ux500/pm.c | 4 ++ arch/arm/mach-ux500/pm_domains.c | 77 ++++++++++++++++++++++++++++++++++++++ arch/arm/mach-ux500/pm_domains.h | 17 +++++++++ 4 files changed, 99 insertions(+) create mode 100644 arch/arm/mach-ux500/pm_domains.c create mode 100644 arch/arm/mach-ux500/pm_domains.h
arch/arm/mach-ux500/Makefile +1 -0
@@ -9,5 +9,6 @@ obj-$(CONFIG_MACH_MOP500) += board-mop500-regulators.o \ board-mop500-audio.o obj-$(CONFIG_SMP) += platsmp.o headsmp.o obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o +obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o CFLAGS_hotplug.o += -march=armv7-a
arch/arm/mach-ux500/pm.c +4 -0
@@ -17,6 +17,7 @@#include <linux/platform_data/arm-ux500-pm.h> #include "db8500-regs.h" +#include "pm_domains.h" /* ARM WFI Standby signal register */ #define PRCM_ARM_WFI_STANDBY (prcmu_base + 0x130)
@@ -191,4 +192,7 @@ void __init ux500_pm_init(u32 phy_base, u32 size)/* Set up ux500 suspend callbacks. */ suspend_set_ops (UX500_SUSPEND_OPS ); + +/* Initialize ux500 power domains */ +ux500_pm_domains_init (); }
arch/arm/mach-ux500/pm_domains.c new file +77 -0
77 lines not on this page · raw message
arch/arm/mach-ux500/pm_domains.h new file +17 -0
@@ -0,0 +1,17 @@ +/* +* Copyright (C) 2014 Linaro Ltd. +* +* Author: Ulf Hansson <[email protected]> +* License terms: GNU General Public License (GPL) version 2 +*/ + +#ifndef __MACH_UX500_PM_DOMAINS_H +#define __MACH_UX500_PM_DOMAINS_H + +#ifdef CONFIG_PM_GENERIC_DOMAINS +extern int __init ux500_pm_domains_init (void ); +#else +static inline int ux500_pm_domains_init (void ) {return 0 ; } +#endif + +#endif
Signature · 1 line
1.7.9.5
PATCH 22/24 ARM: ux500: Enable Kconfig for the generic power domain
In reply to Ulf HanssonSince ux500 uses genpd, this will enable the power domain support.
--- arch/arm/mach-ux500/Kconfig | 1 + 1 file changed, 1 insertion(+)
arch/arm/mach-ux500/Kconfig +1 -0
@@ -33,6 +33,7 @@ config UX500_SOC_DB8500 select PINCTRL_AB8540 select REGULATOR select REGULATOR_DB8500_PRCMU + select PM_GENERIC_DOMAINS if PM menu "Ux500 target platform (boards)"
Signature · 1 line
1.7.9.5
PATCH 23/24 ARM: ux500: Add DT node for ux500 power domains
In reply to Ulf Hansson--- arch/arm/boot/dts/ste-dbx5x0.dtsi | 4 ++++ 1 file changed, 4 insertions(+)
arch/arm/boot/dts/ste-dbx5x0.dtsi +4 -0
@@ -43,6 +43,10 @@ interrupts = <0 7 IRQ_TYPE_LEVEL_HIGH>; }; + pm_domains: pm_domains0 { + compatible = "stericsson,ux500-pm-domains"; + #power-domain-cells = <1>; + }; clocks { compatible = "stericsson,u8500-clks";
Signature · 1 line
1.7.9.5
PATCH 24/24 ARM: ux500: Add sdi[n] devices to VAPE power domain
In reply to Ulf HanssonSince ux500 uses the mmci host driver for these devices and since that driver are well behaving from a runtime PM perspective, we can now add these device to the VAPE power domain.
--- arch/arm/boot/dts/ste-dbx5x0.dtsi | 7 +++++++ 1 file changed, 7 insertions(+)
arch/arm/boot/dts/ste-dbx5x0.dtsi +7 -0
@@ -11,6 +11,7 @@ #include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/mfd/dbx500-prcmu.h> +#include <dt-bindings/arm/ux500_pm_domains.h> #include "skeleton.dtsi" / {
@@ -840,6 +841,7 @@ clocks = <&prcc_kclk 1 5>, <&prcc_pclk 1 5>; clock-names = "sdi", "apb_pclk"; + power-domains = <&pm_domains DOMAIN_VAPE>; status = "disabled"; };
@@ -855,6 +857,7 @@ clocks = <&prcc_kclk 2 4>, <&prcc_pclk 2 6>; clock-names = "sdi", "apb_pclk"; + power-domains = <&pm_domains DOMAIN_VAPE>; status = "disabled"; };
@@ -870,6 +873,7 @@ clocks = <&prcc_kclk 3 4>, <&prcc_pclk 3 4>; clock-names = "sdi", "apb_pclk"; + power-domains = <&pm_domains DOMAIN_VAPE>; status = "disabled"; };
@@ -881,6 +885,7 @@ clocks = <&prcc_kclk 2 5>, <&prcc_pclk 2 7>; clock-names = "sdi", "apb_pclk"; + power-domains = <&pm_domains DOMAIN_VAPE>; status = "disabled"; };
@@ -896,6 +901,7 @@ clocks = <&prcc_kclk 2 2>, <&prcc_pclk 2 4>; clock-names = "sdi", "apb_pclk"; + power-domains = <&pm_domains DOMAIN_VAPE>; status = "disabled"; };
@@ -907,6 +913,7 @@ clocks = <&prcc_kclk 3 7>, <&prcc_pclk 3 7>; clock-names = "sdi", "apb_pclk"; + power-domains = <&pm_domains DOMAIN_VAPE>; status = "disabled"; };
Signature · 1 line
1.7.9.5
cover PM / Domains: Generic OF-based support and cleanups
In reply to Ulf HanssonQuoted 10 lines · Ulf Hansson
Parts of this patchset has been posted earlier. To be able to smoothly continue my work in re-factoring genpd I have collected patches into this patchset.
The complete patchset is available at the linux-pm_linux-next_genpd branch at:
git.linaro.org/people/ulf.hansson/linux-2.6.git
This branch is based upon Rafael's linux-pm tree's linux-next branch.And important note. There are dependencies througout this patchset, which means the all need to go together. I suggest we use Rafael's tree, thus I seek for acks from the affected ARM SoC maintainers.
At least on the surface, there are at least 3 separate series going on here
1) DT support for genpd
2) various genpd cleanups
3) ux500 support
Clearly they are related, but it would be easier to review if a large series like this is broken up into smaller series where the cover letters describe the dependencies between them
Kevin
Rafael J. Wysocki
maintainercover PM / Domains: Generic OF-based support and cleanups
Quoted 16 lines · Kevin Hilman
Quoted 10 lines · Ulf Hansson
Parts of this patchset has been posted earlier. To be able to smoothly continue my work in re-factoring genpd I have collected patches into this patchset.
The complete patchset is available at the linux-pm_linux-next_genpd branch at:
git.linaro.org/people/ulf.hansson/linux-2.6.git
This branch is based upon Rafael's linux-pm tree's linux-next branch.And important note. There are dependencies througout this patchset, which means the all need to go together. I suggest we use Rafael's tree, thus I seek for acks from the affected ARM SoC maintainers.
At least on the surface, there are at least 3 separate series going on here
Quoted 7 lines
1) DT support for genpd
2) various genpd cleanups
3) ux500 supportClearly they are related, but it would be easier to review if a large series like this is broken up into smaller series where the cover letters describe the dependencies between them
Agreed.
And if they are sent in such an order that the bits the rest depends on go first and are settled before the next series is even submitted.
Rafael
cover PM / Domains: Generic OF-based support and cleanups
Quoted 21 lines · Rafael J. Wysocki
Quoted 20 lines · Kevin Hilman
Quoted 10 lines · Ulf Hansson
Parts of this patchset has been posted earlier. To be able to smoothly continue my work in re-factoring genpd I have collected patches into this patchset.
The complete patchset is available at the linux-pm_linux-next_genpd branch at:
git.linaro.org/people/ulf.hansson/linux-2.6.git
This branch is based upon Rafael's linux-pm tree's linux-next branch.And important note. There are dependencies througout this patchset, which means the all need to go together. I suggest we use Rafael's tree, thus I seek for acks from the affected ARM SoC maintainers.
At least on the surface, there are at least 3 separate series going on here
1) DT support for genpd
2) various genpd cleanups
3) ux500 support
Quoted 8 lines
Quoted 3 lines
Clearly they are related, but it would be easier to review if a large series like this is broken up into smaller series where the cover letters describe the dependencies between them
Agreed.
And if they are sent in such an order that the bits the rest depends on go first and are settled before the next series is even submitted.
Right. Let me split it up and resend.
Also, note - the reason for adding the ux500 genpd support in this patchset, was to provide an example of how the new DT bindings would be used.
Kind regards
Ulf Hansson
Quoted 2 lines
Rafael
cover PM / Domains: Generic OF-based support and cleanups
In reply to Ulf HanssonHi Ulf, Tomasz,
Quoted 30 lines · Ulf Hansson
Parts of this patchset has been posted earlier. To be able to smoothly continue my work in re-factoring genpd I have collected patches into this patchset.
The complete patchset is available at the linux-pm_linux-next_genpd branch at:
git.linaro.org/people/ulf.hansson/linux-2.6.git
This branch is based upon Rafael's linux-pm tree's linux-next branch.And important note. There are dependencies througout this patchset, which means the all need to go together. I suggest we use Rafael's tree, thus I seek for acks from the affected ARM SoC maintainers.
Tomasz Figa (3):
base: power: Add generic OF-based power domain look-up
drivercore: Bind/unbind power domain on probe/remove
ARM: exynos: Move to generic power domain bindingsUlf Hansson (21):
PM / Domains: Ignore callbacks for subsysgeneric_pm_domain_dataPM / Domains: Remove the pm_genpd_add|remove_callbacks APIs PM / Domains: Remove system PM callbacks fromgpd_dev_ops
ARM: shmobile: Dropdev_irq_safefrom r8a7779 genpd config
ARM: shmobile: Dropdev_irq_safefrom R-mobile genpd config PM / Domains: Removedev_irq_safefrom genpd config PM / Domains: Remove redundant check forCONFIG_PM
PM / Domains: Remove legacy API for adding devices through DT PM / Domains: Removepm_genpd_syscore_switch()API
PM / Domains: Removegenpd_queue_power_off_work()API PM / Domains: Addlate_initcallto disable unused domains
ARM: exynos: Leave disabling of unused pm domains to genpd
ARM: s3c64xx: Leave disabling of unused pm domains to genpd
Quoted 8 lines
drivers: sh: Leave disabling of unused pm domains to genpd PM / Domains: Remove
default_stop_ok()API
dt: bindings: ux500: Add documentation for power domains
dt: bindings: ux500: Add header for power domains specifiers
ARM: ux500: Initial support for power domains
ARM: ux500: EnableKconfigfor the generic power domain
ARM: ux500: Add DT node for ux500 power domains
ARM: ux500: Add sdi[n] devices to VAPE power domain
What are your plans with this patch series?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
cover PM / Domains: Generic OF-based support and cleanups
Quoted 42 lines · Geert Uytterhoeven
Hi Ulf, Tomasz,
Quoted 30 lines · Ulf Hansson
Parts of this patchset has been posted earlier. To be able to smoothly continue my work in re-factoring genpd I have collected patches into this patchset.
The complete patchset is available at the linux-pm_linux-next_genpd branch at:
git.linaro.org/people/ulf.hansson/linux-2.6.git
This branch is based upon Rafael's linux-pm tree's linux-next branch.And important note. There are dependencies througout this patchset, which means the all need to go together. I suggest we use Rafael's tree, thus I seek for acks from the affected ARM SoC maintainers.
Tomasz Figa (3):
base: power: Add generic OF-based power domain look-up
drivercore: Bind/unbind power domain on probe/remove
ARM: exynos: Move to generic power domain bindingsUlf Hansson (21):
PM / Domains: Ignore callbacks for subsysgeneric_pm_domain_dataPM / Domains: Remove the pm_genpd_add|remove_callbacks APIs PM / Domains: Remove system PM callbacks fromgpd_dev_ops
ARM: shmobile: Dropdev_irq_safefrom r8a7779 genpd config
ARM: shmobile: Dropdev_irq_safefrom R-mobile genpd config PM / Domains: Removedev_irq_safefrom genpd config PM / Domains: Remove redundant check forCONFIG_PM
PM / Domains: Remove legacy API for adding devices through DT PM / Domains: Removepm_genpd_syscore_switch()API
PM / Domains: Removegenpd_queue_power_off_work()API PM / Domains: Addlate_initcallto disable unused domains
ARM: exynos: Leave disabling of unused pm domains to genpd
ARM: s3c64xx: Leave disabling of unused pm domains to genpdQuoted 8 lines
drivers: sh: Leave disabling of unused pm domains to genpd PM / Domains: Remove
default_stop_ok()API
dt: bindings: ux500: Add documentation for power domains
dt: bindings: ux500: Add header for power domains specifiers
ARM: ux500: Initial support for power domains
ARM: ux500: EnableKconfigfor the generic power domain
ARM: ux500: Add DT node for ux500 power domains
ARM: ux500: Add sdi[n] devices to VAPE power domain
Quoted 3 lines
What are your plans with this patch series?
Thanks!
I have been working on the generic power domain DT parts. It needs some more tests, but will for sure post and new patchset early next week.
Then there are two more separate series:
1.. "The genpd cleanup/small-fixes" - I will also post this soon, re-based and separate from the other series.
2. "Genpd support for ux500" - I will keep this one on hold, until the generic power domain DT patchset has been accepted.
Kind regards
Uffe
Quoted 11 lines
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.orgIn personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds