Hi Tero,
On Mon, Jul 30, 2012 at 10:40 AM, Tero Kristo t-kri...@ti.com wrote:
On Fri, 2012-07-27 at 12:36 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
mpu / core powerdomain usecounts are now statically increased
by 1 during MPU activity. This allows the domains to
-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
[Jean Pihet j-pi...@ti.com: ported on top of the functional power
states]
Shouldn't Jean also have signed off?
Sure! I am OK with this change, feel free to add:
Acked-by: Jean Pihet j-pi...@ti.com
Regards,
Jean
Reviewed
Hi Nishant,
On Fri, Jul 13, 2012 at 5:01 AM, Menon, Nishanth n...@ti.com wrote:
On Thu, Jun 14, 2012 at 9:53 AM, Jean Pihet jean.pi...@newoldbits.com wrote:
[..]
--- a/arch/arm/mach-omap2/powerdomain-common.c
+++ b/arch/arm/mach-omap2/powerdomain-common.c
@@ -108,3 +108,74 @@ u32
Hi!
On Fri, Jul 13, 2012 at 7:29 AM, Menon, Nishanth n...@ti.com wrote:
On Fri, Jul 13, 2012 at 12:26 AM, Rajendra Nayak rna...@ti.com wrote:
On Friday 13 July 2012 08:31 AM, Menon, Nishanth wrote:
my Crib about the above apis are lack of logic power state handling:(
which forces code like
Hi!
On Thu, Jun 14, 2012 at 4:53 PM, Jean Pihet jean.pi...@newoldbits.com wrote:
Here is a re-spin after some comments after an internal review and some
testing on
OMAP4 with device OFF support.
Implement the functional states for the power domains:
- unify the API to use the functional
Hi Nishant, Rajendra,
On Fri, Jul 13, 2012 at 1:03 PM, Rajendra Nayak rna...@ti.com wrote:
Hi Nishanth,
On Friday 13 July 2012 03:21 PM, Menon, Nishanth wrote:
On Thursday 05 July 2012, Rajendra Nayak wrote:
[..]
From 5f5e4eb342110286bf719c7d9d7c1959f53e34f9 Mon Sep 17 00:00:00 2001
On Thu, Jul 5, 2012 at 3:03 PM, Rajendra Nayak rna...@ti.com wrote:
Just to give more context, the though of doing something like
what the below RFC does came up as part of the patch review of
Jean's Functional power state series.
My reply crossed yours...
There was also some
offline
Hi Rajendra,
On Wed, Jun 20, 2012 at 10:19 AM, Rajendra Nayak rna...@ti.com wrote:
Hi Jean,
On Friday 01 June 2012 08:41 PM, Jean Pihet wrote:
For a power domain to idle all the clock domains in it must idle.
This patch implements an optimization of the cpuidle code by
denying and later
Hi Rajendra,
On Wed, Jun 20, 2012 at 10:57 AM, Rajendra Nayak rna...@ti.com wrote:
Jean,
On Wednesday 20 June 2012 02:22 PM, Rajendra Nayak wrote:
Hi Jean,
On Wednesday 20 June 2012 02:16 PM, Rajendra Nayak wrote:
On Wednesday 20 June 2012 02:01 PM, Jean Pihet wrote:
Hi Rajendra
Rajendra,
On Wed, Jun 20, 2012 at 12:29 PM, Rajendra Nayak rna...@ti.com wrote:
On Thursday 14 June 2012 08:35 PM, Jean Pihet wrote:
Call the per-device PM QoS functions of the power domain code from the
hwmod layer, in order to apply the constraints requested to a device.
While
On Wed, Jun 20, 2012 at 1:01 PM, Rajendra Nayak rna...@ti.com wrote:
On Thursday 14 June 2012 08:35 PM, Jean Pihet wrote:
{
.enter = omap3_enter_idle_bm,
- .exit_latency = 3000 + 8500
Hi!
Added Paul in Cc:.
On Thu, Jun 14, 2012 at 10:05 AM, Jean Pihet jean.pi...@newoldbits.com wrote:
Hi Richard, all,
On Tue, Jun 12, 2012 at 6:34 PM, Woodruff, Richard r-woodru...@ti.com wrote:
Hi Tony,
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, May 25, 2012 2:53 AM
Hi,
Here are some remarks I got after an internal review. I think those
points need to be discussed with a broader audience.
On Thu, Jun 14, 2012 at 4:53 PM, Jean Pihet jean.pi...@newoldbits.com wrote:
Introduce functional (or logical) states for power domains and the
API functions to read
Hi,
Here are some remarks I got after an internal review. I think those
points need to be discussed with a broader audience.
On Thu, Jun 14, 2012 at 4:53 PM, Jean Pihet jean.pi...@newoldbits.com wrote:
Note: the patch is in RFC state because the state machine for setting
the next power domain
Hi,
Here are some remarks I got after an internal review. I think those
points need to be discussed with a broader audience.
On Thu, Jun 14, 2012 at 5:05 PM, Jean Pihet jean.pi...@newoldbits.com wrote:
When a PM QoS device latency constraint is requested or removed the
constraint is stored
Hi Keshava,
On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
hi kevin
now I am using initramfs with kernel linux3.5.rc1,
but the retention is not working in 3430 sdp. I
Hi Richard, all,
On Tue, Jun 12, 2012 at 6:34 PM, Woodruff, Richard r-woodru...@ti.com wrote:
Hi Tony,
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, May 25, 2012 2:53 AM
Thanks for quick input. Apologies on slow ack of it.
Before we had these frameworks in place it was
tested OK the
code is in RFC state.
v3:
- fix a bug in OMAP3 cpuidle which prevented the IO wake-ups in PER
v2:
- add the logic power states,
- provide the power domains statistics by functional states
v1:
- initial implementation, in RFC state
Jean Pihet (8):
ARM: OMAP2+: PM: protect
omap_set_pwrdm_state is intented to be the only API for changing
a power domain state.
This patch protects the power domains settings and structs from
concurrent accesses to the function by using a mutex.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/pm.c |8
parts; only the external API functions and defines shall be used
by external code, the internal API is only to be used in powerdomain*.[ch]
files.
The memory and logic states are not using the functional states, this
comes as a subsequent patch.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch
-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 61 +++---
arch/arm/mach-omap2/cpuidle44xx.c | 25 +-
arch/arm/mach-omap2/omap-hotplug.c|2 +-
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 43 +---
arch/arm
.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/powerdomain.c | 156 +++--
arch/arm/mach-omap2/powerdomain.h |1 +
2 files changed, 134 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2
Since the power domains logic state is derived from the power domain
functional state and is now programmed from omap_set_pwrdm_state,
the calls to pwrdm_set_logic_retst are removed and the mpu_logic_state
field is removed from the private data of the cpuidle and suspend code.
Signed-off-by: Jean
state and the logic state is programmed from omap_set_pwrdm_state.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/powerdomain-common.c | 41 --
arch/arm/mach-omap2/powerdomain.c | 79 +--
arch/arm/mach-omap2/powerdomain.h
Trace the power domain transitions using the functional power states,
which include the power and logic states.
While at it, fix the trace in the case a power domain did not hit
the desired state, as reported by Paul Walmsley.
Reported-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Jean Pihet j
-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/pm-debug.c| 15 ---
arch/arm/mach-omap2/powerdomain.c | 12 ++--
arch/arm/mach-omap2/powerdomain.h |4 ++--
3 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm
: reworked the error return path and improved the kerneldoc
v2: reworked the OMAP specific cpuidle code to demote the initial C-state to
a valid C-state which fulfills the per-device constraints
v1: initial version
Jean Pihet (10):
ARM: OMAP2+: PM QoS: control the power domains next state from
on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up
latency constraints on MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
[p...@pwsan.com: cleaned some documentation; split set/remove constraint
functions; modified to return
constraints on MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
[p...@pwsan.com: modified to work with omap_devices with large numbers of
hwmods; moved code to mach-omap2/omap_device.c; added documentation; use
notifier return codes]
Signed-off
Call the per-device PM QoS functions of the power domain code from the
hwmod layer, in order to apply the constraints requested to a device.
While at it, correct the functions kerneldoc.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 22
Beagleboard and OMAP4 Pandaboard in RET/OFF using
wake-up latency constraints on MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/powerdomain.c | 215 +
arch/arm/mach-omap2/powerdomain.h | 18 +++
2 files changed, 233 insertions(+), 0
If the next state is no found in the next_valid_state function,
fallback to the default value of C1 (which is state 0).
This prevents the use of a bogus state -1 in the rest of the cpuidle
code.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c |8 +---
1
some numbers when sys_clkreq and sys_offmode are supported
Signed-off-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 52 +++--
1 files changed, 38 insertions(+), 14 deletions(-)
diff --git a/arch/arm
.
The I2C device latency timing is derived from the FIFO size and the
clock speed and so is applicable to all OMAP SoCs.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/plat-omap/i2c.c | 21 -
drivers/i2c/busses/i2c-omap.c | 28 +---
include
/pm_qos.h and
Documentation/power/pm_qos_interface.txt.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
Documentation/arm/OMAP/omap_pm| 68 ++--
arch/arm/plat-omap/include/plat/omap-pm.h | 99 -
arch/arm/plat-omap/omap-pm-noop.c | 88
for MPU and CORE power domains is not lower than the
next state calculated by the per-device PM QoS.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
on MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
---
arch/arm
/Power_Management_Device_Latencies_Measurement
for a detailed explanation on where are the numbers coming from.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
on MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach
Hi Tero,
I have a few remarks regarding the genericity of this code. I think it
is better if the code in powerdomain.c stays generic and that the
platform specific checks and operations be moved in the specific
functions (via the pwrdm_ops struct).
On Tue, Jun 12, 2012 at 5:31 PM, Tero Kristo
Hi Tomi,
On Tue, May 22, 2012 at 12:09 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hi Florian,
Here are the OMAP DSS changes for 3.5.
I really tried this time to send the pull request early, but here I am
again, sending it when the merge window has already opened... A few
late-found
Hi Tomi,
On Tue, Jun 5, 2012 at 2:33 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hi Jean,
On Tue, 2012-06-05 at 14:17 +0200, Jean Pihet wrote:
Hi Tomi,
I am using a mainline kernel (3.5.0-rc1) with the patches below integrated.
I have an issue with suspend/resume on OMAP3 Beagleboard
NAND flash
to /dev/null.
[1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
Jean Pihet (3):
ARM: OMAP3: PM: cpuidle: default to C1 in next_valid_state
ARM: OMAP3: PM: cpuidle: optimize the PER latency in C1 state
ARM: OMAP3: PM: cpuidle: optimize the clkdm idle
If the next state is no found in the next_valid_state function,
fallback to the default value of C1 (which is state 0).
This prevents the use of a bogus state -1 in the rest of the cpuidle
code.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c |8 +---
1
-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 41 +++-
1 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index f619a92..2e2f1c6 100644
--- a/arch/arm
and _cpuidle_deny_idle are
not used anymore and so are removed.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 22 --
1 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2
Hi Kevin,
On Thu, May 31, 2012 at 6:29 PM, Kevin Hilman khil...@ti.com wrote:
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
It is not needed to iterate through all the clock domains of a
power domain in order to allow or deny it to idle.
Why? (I know the answer
On Fri, Jun 1, 2012 at 6:26 PM, Kevin Hilman khil...@ti.com wrote:
Hi Jean,
Jean Pihet jean.pi...@newoldbits.com writes:
The C1 state latency can be improved by optimizing the cpuidle low
level code.
The first patch is a precaution fix for patch 2.
Patches 2 3 are optimization changes
Hi Tomi, Paul!
On Fri, May 25, 2012 at 10:24 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Thu, 2012-05-24 at 18:39 -0600, Paul Walmsley wrote:
cc Jean
Hello Tomi,
On Wed, 16 May 2012, Tomi Valkeinen wrote:
I also suspect that this could be just a plain DSS bug. The default FIFO
Hi Santosh,
On Thu, May 17, 2012 at 12:04 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Jean,
On Tuesday 08 May 2012 02:10 PM, Jean Pihet wrote:
Paul,
On Mon, May 7, 2012 at 11:28 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
On Wed, 18 Apr 2012, jean.pi...@newoldbits.com wrote
Hi Tero, Kevin, Santosh,
On Mon, May 21, 2012 at 10:48 AM, Tero Kristo t-kri...@ti.com wrote:
On Wed, 2012-05-16 at 15:36 -0700, Kevin Hilman wrote:
+Jean for functional power states
Tero Kristo t-kri...@ti.com writes:
This patch adds device off support to OMAP4 device type.
Description
Hi Mark,
On Mon, Apr 30, 2012 at 11:26 PM, Mark A. Greer mgr...@animalcreek.com wrote:
From: Mark A. Greer mgr...@animalcreek.com
The am35x family of SoCs only support the PWRSTS_ON
state so create a new set of powerdomain structures
that ensure that only the ON state is entered.
From: Jean Pihet j-pi...@ti.com
One of the main contributors of the low power code latency is
the PER power domain. To optimize the high-performance and
low-latency C1 state, prevent any PER state which is lower
than the CORE state in C1.
Reported and suggested by Kevin Hilman.
Reported
From: Jean Pihet j-pi...@ti.com
It is not needed to iterate through all the clock domains of a
power domain in order to allow or deny it to idle.
This patch allows or denies only the first registered clock domain
of a power domain, and so optimizes the latency of the low power
code. The functions
Hi Kevin,
On Mon, May 7, 2012 at 7:31 PM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
On Tue, May 1, 2012 at 7:27 PM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
HI Kevin, Grazvydas,
On Tue, Apr 24, 2012 at 4:29 PM
Hi Paul,
Thanks for the review. Do you plan to review the full set before I
start to address the comments.
On Mon, May 7, 2012 at 8:41 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
On Wed, 18 Apr 2012, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
Signed-off-by: Jean Pihet
Paul,
On Mon, May 7, 2012 at 11:28 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
On Wed, 18 Apr 2012, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
Introduce functional (or logical) states for power domains and the
API functions to read the power domains settings
Hi Benoit,
On Tue, May 8, 2012 at 1:01 PM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Kevin Jon,
On 5/8/2012 1:28 AM, Kevin Hilman wrote:
Jon Hunterjon-hun...@ti.com writes:
Hi Kevin,
On 05/07/2012 12:15 PM, Kevin Hilman wrote:
Jon Hunterjon-hun...@ti.com writes:
Hi Will,
On
On Tue, May 8, 2012 at 2:37 PM, Cousson, Benoit b-cous...@ti.com wrote:
Salut Jean,
On 5/8/2012 1:23 PM, Jean Pihet wrote:
Hi Benoit,
On Tue, May 8, 2012 at 1:01 PM, Cousson, Benoitb-cous...@ti.com wrote:
Hi Kevin Jon,
On 5/8/2012 1:28 AM, Kevin Hilman wrote:
Jon Hunterjon-hun
Hi Mark,
On Thu, May 3, 2012 at 12:04 AM, Mark A. Greer mgr...@animalcreek.com wrote:
On Tue, May 01, 2012 at 10:47:35AM +0200, Jean Pihet wrote:
Hi Mark,
Hi Jean. Thanks for the review.
On Mon, Apr 30, 2012 at 11:25 PM, Mark A. Greer mgr...@animalcreek.com
wrote:
From: Mark A. Greer
Hi Jon, Vaibhav,
On Thu, May 3, 2012 at 8:38 AM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
On Tue, May 01, 2012 at 21:07:39, Hunter, Jon wrote:
[...]
int pwrdm_read_pwrst(struct powerdomain *pwrdm)
{
- int ret = -EINVAL;
+ int pwrst, ret = -EINVAL;
if (!pwrdm)
Hi Tero,
On Fri, Apr 20, 2012 at 11:19 AM, Tero Kristo t-kri...@ti.com wrote:
PM debug now contains a file that can be used to control OSWR support
enable / disable on OMAP4. Also removed the off_mode_enable file for
the same platform as it is unsupported.
Signed-off-by: Tero Kristo
On Tue, May 1, 2012 at 7:27 PM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
HI Kevin, Grazvydas,
On Tue, Apr 24, 2012 at 4:29 PM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
Hi Grazvydas, Kevin,
I did some gather
Hi Kevin,
On Tue, May 1, 2012 at 1:15 AM, Kevin Hilman khil...@ti.com wrote:
Hi Jean,
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
. Implement the devices wake-up latency constraints using the global
device PM QoS notification handler which applies the constraints
Hi Mark,
On Mon, Apr 30, 2012 at 11:25 PM, Mark A. Greer mgr...@animalcreek.com wrote:
From: Mark A. Greer mgr...@animalcreek.com
Some parts of the OMAP code assume that all power
domains support certain states (e.g., RET OFF).
This isn't always true (e.g., the am35x family of
SoC's) so
From: Jean Pihet j-pi...@ti.com
The OMAP3 PRCM registers accesses are known to be slow, with a PRCM register
read taking up to 12-14us depending on the OPP.
This patch adds a caching mechanism on the power domains state registers.
When the cache is cold or has been invalidated a register access
From: Jean Pihet j-pi...@ti.com
The OMAP3 PRCM registers accesses are known to be slow. A PRCM read
can take up to 12-14us depending on the OPP.
This patch adds a caching mechanism on the power domains state registers.
When the cache is cold or has been invalidated a register access is
performed
From: Jean Pihet j-pi...@ti.com
Use the caching API for the previous, current and next power domains states.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/powerdomain.c | 32 ++--
1 files changed, 26 insertions(+), 6 deletions(-)
diff --git
From: Jean Pihet j-pi...@ti.com
Use the caching API for the previous, current and next
power domains logical and memory states.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/powerdomain.c | 108 -
1 files changed, 82 insertions(+), 26
From: Jean Pihet j-pi...@ti.com
The power domains registers cache is partially invalidated when clearing
the previous power states and after coming back from the low power mode,
i.e. after the return from the low level WFI instruction.
Note: this invalidate use scheme is optimized
From: Jean Pihet j-pi...@ti.com
Use the caching API instead of using the internal pwrdm-state field
for PM debug statistics display.
Note: some power domains states mismatch messages can be printed out with
the power domains states statstics, indicating that the power domains are
not controlled
HI Kevin, Grazvydas,
On Tue, Apr 24, 2012 at 4:29 PM, Kevin Hilman khil...@ti.com wrote:
Jean Pihet jean.pi...@newoldbits.com writes:
Hi Grazvydas, Kevin,
I did some gather some performance measurements and statistics using
custom tracepoints in __omap3_enter_idle.
I posted the patches
Hi Kevin,
On Fri, Apr 27, 2012 at 1:29 AM, Kevin Hilman khil...@ti.com wrote:
This flag is no longer used since clock init all AM35x devices
is now the same.
Acked-by: Vaibhav Hiremath hvaib...@ti.com
Tested-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
Kevin,
On Fri, Apr 27, 2012 at 1:29 AM, Kevin Hilman khil...@ti.com wrote:
The 3505 check is now unused and can be removed.
There are no longer any cpu_is_* checks that depend on specific IP
detection.
Acked-by: Vaibhav Hiremath hvaib...@ti.com
Tested-by: Vaibhav Hiremath hvaib...@ti.com
Hi Grazvydas, Kevin,
I did some gather some performance measurements and statistics using
custom tracepoints in __omap3_enter_idle.
All the details are at
http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#C1_performance_problem:_analysis
.
The setup is:
- Beagleboard
Hi Tero,
On Tue, Apr 24, 2012 at 2:21 PM, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2012-04-24 at 16:08 +0530, Santosh Shilimkar wrote:
+ Tero
On Tuesday 24 April 2012 03:20 PM, Jean Pihet wrote:
Hi Grazvydas, Kevin,
I did some gather some performance measurements and statistics using
Hi Arnd,
On Thu, Apr 19, 2012 at 3:54 PM, Arnd Bergmann a...@arndb.de wrote:
On Thursday 05 April 2012, Trilok Soni wrote:
Couple of suggestions:
drivers/platform/omap/avs?
drivers/misc/omap/avs?
I would definitely prefer something under drivers/power,
drivers/regulators or a new
classes of operations for
OMAP chips, etc.
Keerthy J is taking over the ownership of this code and will continue
the development further.
What do you think?
Regards,
Jean
On Mon, Mar 19, 2012 at 5:12 PM, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
AVS is a power
From: Jean Pihet j-pi...@ti.com
Implement the functional states for the power domains:
- protect the power domain state change by a mutex in
omap_set_pwrdm_state,
- introduce the functional states for power domains power states and
logic power states, and the conversion functions between
From: Jean Pihet j-pi...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/pm.c |8 ++--
arch/arm/mach-omap2/powerdomain.c |1 +
arch/arm/mach-omap2/powerdomain.h |3 ++-
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach
From: Jean Pihet j-pi...@ti.com
Introduce functional (or logical) states for power domains and the
API functions to read the power domains settings and to convert
between the functional (i.e. logical) and the internal (or registers)
values.
OMAP2, OMAP3 and OMAP4 platforms are defining
From: Jean Pihet j-pi...@ti.com
In the new API the functions pwrdm_*_logic_* and pwrdm_*_mem_* take the
functional states as parameter.
OMAP2, OMAP3 and OMAP4 platforms are defining a conversion routine
between the functional state and the logic power state.
The power domains logic state is now
From: Jean Pihet j-pi...@ti.com
Use the functional power states as the API to control power domains.
The omap_set_pwrdm_state function shall be used instead of
pwrdm_set_next_pwrst to control the power domains next states.
Note: the internal code for power domains state management still
uses
From: Jean Pihet j-pi...@ti.com
Since the power domains logic state is derived from the power domain
functional state and is now programmed from omap_set_pwrdm_state,
the calls to pwrdm_set_logic_retst are removed and the mpu_logic_state
field is removed from the private data of the cpuidle
From: Jean Pihet j-pi...@ti.com
The PM code uses some counters to keep track of the power domains
transitions, in order to provide the information to drivers (in
pwrdm_get_context_loss_count) and to expose the information to
sysfs for debug purpose.
This patch provides the information for each
From: Jean Pihet j-pi...@ti.com
. Implement the devices wake-up latency constraints using the global
device PM QoS notification handler which applies the constraints to the
underlying layer,
. Implement the low level code which controls the power domains next
functional power states [3
From: Jean Pihet j-pi...@ti.com
Call the per-device PM QoS functions of the power domain code from the
hwmod layer, in order to apply the constraints requested to a device.
While at it, correct the functions kerneldoc.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2
From: Jean Pihet j-pi...@ti.com
When a PM QoS device latency constraint is requested or removed the
constraint is stored in the constraints list of the corresponding power
domain, then the aggregated constraint value is applied by programming
the next functional power state using
From: Jean Pihet j-pi...@ti.com
Implement the devices wake-up latency constraints using the global
device PM QoS notification handler which applies the constraints to the
underlying layer by calling the corresponding function at hwmod level.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard
From: Jean Pihet j-pi...@ti.com
The MPU latency figures for cpuidle include the MPU itself and also
the peripherals needed for the MPU to execute instructions (e.g.
main memory, caches, IRQ controller, MMU etc). On OMAP3 those
peripherals belong to the MPU and CORE power domains and so
From: Jean Pihet j-pi...@ti.com
Figures are added to the power domains structs for RET and OFF modes.
Note: the latency figures for MPU, PER, CORE, NEON have been obtained
from actual measurements.
The latency figures for the other power domains are preliminary and
shall be added.
Cf. http
From: Jean Pihet j-pi...@ti.com
Update the data from the measurements performed at HW and SW levels.
Cf. http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement
for a detailed explanation on where are the numbers coming from.
ToDo:
- Measure the wake-up latencies for all
From: Jean Pihet j-pi...@ti.com
Remove the following functions from the OMAP PM API and the callers
(currently only I2C driver):
omap_pm_set_max_mpu_wakeup_lat
omap_pm_set_max_dev_wakeup_lat
omap_pm_set_max_sdma_lat
and updated the kernel Documentation accordingly.
The generic per-device PM
From: Jean Pihet j-pi...@ti.com
Remove the following functions from the OMAP PM API:
omap_pm_set_max_mpu_wakeup_lat
omap_pm_set_max_dev_wakeup_lat
omap_pm_set_max_sdma_lat
and updated the kernel Documentation accordingly.
The generic per-device PM QoS functions shall be used instead
On Wed, Apr 18, 2012 at 5:18 PM, Grazvydas Ignotas nota...@gmail.com wrote:
On Wed, Apr 18, 2012 at 4:45 PM, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
Update the data from the measurements performed at HW and SW levels.
Cf.
http://www.omappedia.org/wiki
Hi Kevin,
Adding Keerthy J
On Wed, Apr 18, 2012 at 7:27 PM, Kevin Hilman khil...@ti.com wrote:
Hi Jean,
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
Move some functions from mach-omap2/ dir to the plat/ dir.
The SmartReflex class driver is a user of the basic voltage
Kevin,
On Wed, Apr 18, 2012 at 7:33 PM, Kevin Hilman khil...@ti.com wrote:
+Benoit
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
Change the name field value to better reflect the smartreflex
integration in the system
Signed-off-by: Jean Pihet j-pi...@ti.com
On Wed, Apr 18, 2012 at 8:21 PM, Kevin Hilman khil...@ti.com wrote:
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
The SmartReflex driver incorrectly treats some per-OPP data as data
common to all OPPs (e.g., ERRMINLIMIT). Move this data into a per-OPP
data structure
From: Jean Pihet j-pi...@ti.com
Implement the functional states for the power domains:
- protect the power domain state change by a mutex in
omap_set_pwrdm_state,
- introduce the functional states for power domains power states and
logic power states, and the conversion functions between
From: Jean Pihet j-pi...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/pm.c |8 ++--
arch/arm/mach-omap2/powerdomain.c |1 +
arch/arm/mach-omap2/powerdomain.h |3 ++-
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach
From: Jean Pihet j-pi...@ti.com
Introduce functional (or logical) states for power domains and the
API functions to read the power domains settings and to convert
between the functional (i.e. logical) and the internal (or registers)
values.
OMAP2, OMAP3 and OMAP4 platforms are defining
From: Jean Pihet j-pi...@ti.com
Use the functional power states as the API to control power domains.
The omap_set_pwrdm_state function shall be used instead of
pwrdm_set_next_pwrst to control the power domains next states.
Note: the internal code for power domains state management still
uses
101 - 200 of 931 matches
Mail list logo
