From: Jean Pihet <j-pihet@xxxxxx>
This patch set is in an RFC state, for review and comments.
In order to implement the new class in PM QoS the following changes have been
made:
1. Add a new PM QoS class for device wake-up constraints
(PM_QOS_DEV_WAKEUP_LATENCY).
Due to the per-device nature of the new class the constraints lists are stored
inside the device dev_pm_info struct instead of the internal per-class
constraints lists.
The new class is only available from kernel drivers and so is not exported to
user space.
2. Added a notification of device insertion/removal from the device PM framework
to PM QoS.
This allows to init/de-init the per-device constraints list upon device insertion
and removal.
RFC state for comments and review, barely tested
3. Make the pm_qos_add_request API more generic by using a
struct pm_qos_parameters parameter. This allows easy extension in the future.
4. Upon a change of the strongest constraint in the PM_QOS_DEV_WAKEUP_LATENCY
class a notification chain mechanism is used to take action on the system.
This is the proposed way to have PM QoS and the platform dependant code to
interact with each other, cf. 4 below.
The notification mechanism now passes the constraint request struct ptr in
order for the notifier callback to have access to the full set of constraint
data, e.g. the struct device ptr.
5. cpuidle interaction with the OMAP3 cpuidle handler
Since cpuidle is a CPU centric framework it decides the MPU next power state
based on the MPU exit_latency and target_residency figures.
The rest of the power domains get their next power state programmed from
the PM_QOS_DEV_WAKEUP_LATENCY class of the PM QoS framework, via the device
wake-up latency constraints.
Note: the exit_latency and target_residency figures of the MPU include the MPU
itself and the peripherals needed for the MPU to execute instructions (e.g.
main memory, caches, IRQ controller, MMU etc).
Some of those peripherals can belong to other power domains than the MPU
subsystem and so the corresponding latencies must be included in those figures.
6. Update the pm_qos_add_request callers to the generic API
7. Minor clean-ups and rename of struct fields
Questions:
1. How to retrieve the device ptr from a given device driver in order to add
a constraint on it?
2. The device struct has recently been extended with the power domain
information. Can this be used to apply the constraints on power domains?
On-going developments, patches in preparation:
1. write Documentation for the new PM QoS class
2. validate the constraints framework on OMAP4 HW (done on OMAP3)
3. refine the power domains wake-up latency and the cpuidle figures
Based on the master branch of the linux-omap git tree (3.0.0-rc3). Compile
tested using OMAP and x86 generic defconfigs.
Tested on OMAP3 Beagleboard (ES2.x) with full RETention and OFF modes.
Changelog:
v2:
. Rework after comments on the mailing lists
. Added a notification of device insertion/removal from the device PM framework
. Validated on OMAP3 HW
Jean Pihet (10):
PM: add a per-device wake-up latency constraints plist
PM: extend PM QoS with per-device wake-up constraints
PM QoS: support the dynamic devices insertion and removal
OMAP PM: create a PM layer plugin for per-device constraints
OMAP PM: early init of the pwrdms states
OMAP2+: powerdomain: control power domains next state
OMAP3: powerdomain data: add wake-up latency figures
OMAP2+: omap_hwmod: manage the wake-up latency constraints
OMAP: PM CONSTRAINTS: implement the devices wake-up latency
constraints
OMAP2+: cpuidle only influences the MPU state
Vishwanath BS (1):
OMAP4: powerdomain data: add wake-up latency figures
arch/arm/mach-omap2/cpuidle34xx.c | 42 +---
arch/arm/mach-omap2/omap_hwmod.c | 26 ++-
arch/arm/mach-omap2/pm.h | 17 ++-
arch/arm/mach-omap2/pm34xx.c | 2 +-
arch/arm/mach-omap2/pm44xx.c | 2 +-
arch/arm/mach-omap2/powerdomain.c | 190 ++++++++++++++
arch/arm/mach-omap2/powerdomain.h | 33 +++-
arch/arm/mach-omap2/powerdomains3xxx_data.c | 77 ++++++
arch/arm/mach-omap2/powerdomains44xx_data.c | 85 +++++++
arch/arm/plat-omap/Kconfig | 7 +
arch/arm/plat-omap/Makefile | 1 +
arch/arm/plat-omap/i2c.c | 20 --
arch/arm/plat-omap/include/plat/omap-pm.h | 128 ----------
arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +
arch/arm/plat-omap/omap-pm-constraints.c | 344 ++++++++++++++++++++++++++
arch/arm/plat-omap/omap-pm-noop.c | 89 -------
drivers/base/power/main.c | 5 +
drivers/i2c/busses/i2c-omap.c | 35 ++-
drivers/media/video/via-camera.c | 5 +-
drivers/net/e1000e/netdev.c | 9 +-
drivers/net/wireless/ipw2x00/ipw2100.c | 6 +-
include/linux/pm.h | 3 +
include/linux/pm_qos_params.h | 42 ++--
kernel/pm_qos_params.c | 231 ++++++++++++------
sound/core/pcm_native.c | 8 +-
25 files changed, 1023 insertions(+), 386 deletions(-)
create mode 100644 arch/arm/plat-omap/omap-pm-constraints.c
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
