All of lore.kernel.org
 help / color / mirror / Atom feed
From: jean.pihet@newoldbits.com
To: "Rafael J. Wysocki" <rjw@sisk.pl>, Paul Walmsley <paul@pwsan.com>,
	Kevin Hilman <khilman@ti.com>,
	Magnus Damm <magnus.damm@gmail.com>,
	Linux PM mailing list <linux-pm@lists.linux-foun>
Cc: Jean Pihet <j-pihet@ti.com>
Subject: [RFC/PATCH 0/9] PM QoS: add a per-device wake-up latency constraint class
Date: Fri, 24 Jun 2011 17:30:45 +0200	[thread overview]
Message-ID: <1308929445-31289-1-git-send-email-j-pihet@ti.com> (raw)
In-Reply-To: <1308926286-30445-1-git-send-email-j-pihet@ti.com>

From: Jean Pihet <j-pihet@ti.com>

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. Make the pm_qos_add_request API more generic by using a
struct pm_qos_parameters parameter. This allows easy extension in the future.

3. 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.

4. 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 this figure.

5. Update the pm_qos_add_request callers to the generic API

6. 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 OMAP3&4 HW
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 only using OMAP and x86 generic defconfigs.


Jean Pihet (8):
  PM: add a per-device wake-up latency constraints plist
  PM: extend PM QoS with per-device wake-up constraints
  OMAP PM: create a PM layer plugin for per-device constraints
  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/powerdomain.c            |  187 ++++++++++++++
 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                    |    1 +
 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                           |    2 +
 include/linux/pm_qos_params.h                |   40 ++--
 kernel/pm_qos_params.c                       |  142 ++++++-----
 sound/core/pcm_native.c                      |    8 +-
 23 files changed, 939 insertions(+), 367 deletions(-)
 create mode 100644 arch/arm/plat-omap/omap-pm-constraints.c

-- 
1.7.4.1


  parent reply	other threads:[~2011-06-24 15:31 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-24 14:37 [RFC/PATCH 0/9] PM QoS: add a per-device wake-up latency constraint class jean.pihet
2011-06-24 14:37 ` [RFC/PATCH 1/9] PM: add a per-device wake-up latency constraints plist jean.pihet
2011-06-24 14:37 ` jean.pihet
2011-06-24 14:37 ` [RFC/PATCH 2/9] PM: extend PM QoS with per-device wake-up constraints jean.pihet
2011-06-24 14:37 ` jean.pihet
2011-06-24 14:38 ` [RFC/PATCH 3/9] OMAP PM: create a PM layer plugin for per-device constraints jean.pihet
2011-06-24 14:38 ` jean.pihet
2011-06-24 14:38 ` [RFC/PATCH 4/9] OMAP2+: powerdomain: control power domains next state jean.pihet
2011-06-24 14:38 ` jean.pihet
2011-06-24 14:38 ` [RFC/PATCH 5/9] OMAP3: powerdomain data: add wake-up latency figures jean.pihet
2011-06-24 14:38 ` jean.pihet
2011-06-24 14:38 ` [RFC/PATCH 6/9] OMAP4: " jean.pihet
2011-06-24 14:38 ` jean.pihet
2011-06-24 14:38 ` [RFC/PATCH 7/9] OMAP2+: omap_hwmod: manage the wake-up latency constraints jean.pihet
2011-06-24 14:38 ` jean.pihet
2011-06-24 14:38 ` [RFC/PATCH 8/9] OMAP: PM CONSTRAINTS: implement the devices " jean.pihet
2011-06-24 14:38 ` jean.pihet
2011-06-27 18:33   ` Todd Poynor
2011-06-27 18:33   ` Todd Poynor
2011-06-30 15:08     ` Jean Pihet
2011-06-30 15:08     ` Jean Pihet
2011-06-24 14:38 ` [RFC/PATCH 9/9] OMAP2+: cpuidle only influences the MPU state jean.pihet
2011-06-24 14:38 ` jean.pihet
2011-06-25 13:23   ` Santosh Shilimkar
2011-06-27  6:53     ` Jean Pihet
2011-06-27 14:11       ` Santosh Shilimkar
2011-06-27 14:31         ` Jean Pihet
2011-06-27 14:31         ` Jean Pihet
2011-06-27 14:11       ` Santosh Shilimkar
2011-06-25 13:23   ` Santosh Shilimkar
2011-06-24 15:30 ` [RFC/PATCH 0/9] PM QoS: add a per-device wake-up latency constraint class jean.pihet
2011-06-24 15:30 ` jean.pihet [this message]
2011-06-27 13:40 ` [linux-pm] " mark gross
2011-06-30 15:07   ` Jean Pihet
2011-06-30 15:07   ` Jean Pihet
2011-06-27 13:40 ` mark gross
2011-06-24 14:37 jean.pihet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1308929445-31289-1-git-send-email-j-pihet@ti.com \
    --to=jean.pihet@newoldbits.com \
    --cc=j-pihet@ti.com \
    --cc=khilman@ti.com \
    --cc=linux-pm@lists.linux-foun \
    --cc=magnus.damm@gmail.com \
    --cc=paul@pwsan.com \
    --cc=rjw@sisk.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.