From: Jean Pihet j-pi...@ti.com
The PM QoS implementation files are better named
kernel/power/qos.c and include/linux/pm_qos.h.
The PM QoS support is compiled under the CONFIG_PM option.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-msm/clock.c |2 +-
drivers/acpi
From: Jean Pihet j-pi...@ti.com
- Misc fixes to improve code readability:
. rename struct pm_qos_request_list to struct pm_qos_request,
. rename pm_qos_req parameter to req in internal code,
consistenly use req in the API parameters,
. update the in-kernel API callers to the new parameters
From: Jean Pihet j-pi...@ti.com
Move around the PM QoS misc devices management code
for better readability.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
kernel/power/qos.c | 45 +++--
1 files changed, 23 insertions(+), 22 deletions(-)
diff --git
From: Jean Pihet j-pi...@ti.com
In preparation for the per-device constratins support, re-organize
the data strctures:
- add a struct pm_qos_constraints which contains the constraints
related data
- update struct pm_qos_object contents to the PM QoS internal object
data. Add a pointer to struct
From: Jean Pihet j-pi...@ti.com
In preparation for the per-device constratins support:
- rename update_target to pm_qos_update_target
- generalize and export pm_qos_update_target for usage by the upcoming
per-device latency constraints framework:
. operate on struct pm_qos_constraints
From: Jean Pihet j-pi...@ti.com
Add a global notification chain that gets called upon changes to the
aggregated constraint value for any device.
The notification callbacks are passing the full constraint request data
in order for the callees to have access to it. The current use
From: Jean Pihet j-pi...@ti.com
Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat
API to the new PM QoS API.
Since the constraint is on the MPU subsystem, use the PM_QOS_CPU_DMA_LATENCY
class of PM QoS. The resulting MPU constraints are used by cpuidle to
decide the next power
From: Jean Pihet j-pi...@ti.com
Created arch/arm/plat-omap/omap-pm-constraints.c file from
arch/arm/plat-omap/omap-pm-noop.c and the associated Kconfig option
OMAP_PM_CONSTRAINTS.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/plat-omap/Kconfig |7 +
arch/arm/plat-omap
From: Jean Pihet j-pi...@ti.com
When a PM QoS device latency constraint is requested or removed the
PM QoS layer notifies the underlying layer with the updated aggregated
constraint value. The constraint is stored in the powerdomain constraints
list and then applied to the corresponding power
From: Jean Pihet j-pi...@ti.com
Figures are added to the power domains structs.
Note: the figures are preliminary figures. More accurate measurements
are needed. Also the conditions of measurements shall be investigated
and described.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency
wake-up latency constraints on
MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/powerdomains44xx_data.c | 84 +++
1 files changed, 84 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
b/arch/arm
From: Jean Pihet j-pi...@ti.com
Hwmod is queried from the OMAP_PM layer to manage the power domains
wake-up latency constraints. Hwmod retrieves the correct power domain
and if it exists it calls the corresponding power domain function.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF
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.
Note: the bus throughput function is implemented
From: Jean Pihet j-pi...@ti.com
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 devices PM QoS framework, via the devices wake-up
From: Jean Pihet j-pi...@ti.com
Implement the per-device PM QoS constraints by creating a device
PM QoS API, which calls the PM QoS constraints management core code.
The per-device latency constraints data strctures are stored
in the device dev_pm_info struct.
The device PM code calls the init
On Tue, Aug 16, 2011 at 4:25 PM, Santosh santosh.shilim...@ti.com wrote:
On Tuesday 16 August 2011 07:13 PM, jean.pi...@newoldbits.com wrote:
From: Jean Pihetj-pi...@ti.com
Figures are added to the power domains structs.
Note: the figures are preliminary figures. More accurate measurements
On Tue, Aug 16, 2011 at 4:26 PM, Santosh santosh.shilim...@ti.com wrote:
On Tuesday 16 August 2011 07:13 PM, jean.pi...@newoldbits.com wrote:
From: Vishwanath BSvishwanath...@ti.com
This patch adds wake up latency numbers for OMAP4. Note that these are
preliminary numbers and need to be
Hi Rafael, Mark,
On Sat, Aug 13, 2011 at 10:34 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Saturday, August 13, 2011, mark gross wrote:
On Thu, Aug 11, 2011 at 05:06:42PM +0200, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
In preparation for the per-device constratins
Rafael, Mark,
On Sat, Aug 13, 2011 at 10:58 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Saturday, August 13, 2011, mark gross wrote:
On Thu, Aug 11, 2011 at 05:06:41PM +0200, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
In preparation for the per-device constratins
Rafael,
2011/8/13 Rafael J. Wysocki r...@sisk.pl:
Hi,
Well, it looks like I should have reviewed this one more carefully.
On Thursday, August 11, 2011, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
Implement the per-device PM QoS constraints by creating a device
PM QoS
Rafael,
On Fri, Aug 12, 2011 at 11:56 PM, Rafael J. Wysocki r...@sisk.pl wrote:
Hi,
On Friday, August 12, 2011, Jean Pihet wrote:
Hi Rafael,
2011/8/12 Rafael J. Wysocki r...@sisk.pl:
On Thursday, August 11, 2011, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
Hi Rafael,
2011/8/12 Rafael J. Wysocki r...@sisk.pl:
On Thursday, August 11, 2011, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
This patch set is in an RFC state, for review and comments.
...
Questions:
1. the user space API is still under discussions on linux-omap
From: Jean Pihet j-pi...@ti.com
This patch set is in an RFC state, for review and comments.
High level implementation:
1. Preparation of the PM QoS for the addition of a device PM QoS constraints
framework:
. rename and move of the PM QoS implementation files to kernel/power/qos.c
From: Jean Pihet j-pi...@ti.com
The PM QoS implementation files are better named
kernel/power/qos.c and include/linux/pm_qos.h.
The PM QoS support is compiled under the CONFIG_PM option.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-msm/clock.c |2 +-
drivers/acpi
From: Jean Pihet j-pi...@ti.com
- Misc fixes to improve code readability:
. rename struct pm_qos_request_list to struct pm_qos_request,
. rename pm_qos_req parameter to req in internal code,
consistenly use req in the API parameters,
. update the in-kernel API callers to the new parameters
From: Jean Pihet j-pi...@ti.com
Move around the PM QoS misc devices management code
for better readability.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
kernel/power/qos.c | 45 +++--
1 files changed, 23 insertions(+), 22 deletions(-)
diff --git
From: Jean Pihet j-pi...@ti.com
In preparation for the per-device constratins support, re-organize
the data strctures:
- add a struct pm_qos_constraints which contains the constraints
related data
- update struct pm_qos_object contents to the PM QoS internal object
data. Add a pointer to struct
From: Jean Pihet j-pi...@ti.com
In preparation for the per-device constratins support:
- rename update_target to pm_qos_update_target
- generalize and export pm_qos_update_target for usage by the upcoming
per-device latency constraints framework:
. operate on struct pm_qos_constraints
From: Jean Pihet j-pi...@ti.com
Implement the per-device PM QoS constraints by creating a device
PM QoS API, which calls the PM QoS constraints management core code.
The per-device latency constraints data strctures are stored
in the device dev_pm_info struct.
The device PM code calls the init
From: Jean Pihet j-pi...@ti.com
Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat
API to the new PM QoS API.
Since the constraint is on the MPU subsystem, use the PM_QOS_CPU_DMA_LATENCY
class of PM QoS. The resulting MPU constraints are used by cpuidle to
decide the next power
From: Jean Pihet j-pi...@ti.com
Add a global notification chain that gets called upon changes to the
aggregated constraint value for any device.
The notification callbacks are passing the full constraint request data
in order for the callees to have access to it. The current use
From: Jean Pihet j-pi...@ti.com
Created arch/arm/plat-omap/omap-pm-constraints.c file from
arch/arm/plat-omap/omap-pm-noop.c and the associated Kconfig option
OMAP_PM_CONSTRAINTS.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/plat-omap/Kconfig |7 +
arch/arm/plat-omap
From: Jean Pihet j-pi...@ti.com
When a PM QoS device latency constraint is requested or removed the
PM QoS layer notifies the underlying layer with the updated aggregated
constraint value. The constraint is stored in the powerdomain constraints
list and then applied to the corresponding power
From: Jean Pihet j-pi...@ti.com
Figures are added to the power domains structs.
Note: the figures are preliminary figures. More accurate measurements
are needed. Also the conditions of measurements shall be investigated
and described.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency
wake-up latency constraints on
MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/powerdomains44xx_data.c | 84 +++
1 files changed, 84 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
b/arch/arm
From: Jean Pihet j-pi...@ti.com
Hwmod is queried from the OMAP_PM layer to manage the power domains
wake-up latency constraints. Hwmod retrieves the correct power domain
and if it exists it calls the corresponding power domain function.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF
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.
Note: the bus throughput function is implemented
From: Jean Pihet j-pi...@ti.com
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 devices PM QoS framework, via the devices wake-up
Hi Todd,
On Fri, Jul 29, 2011 at 8:00 PM, Todd Poynor toddpoy...@google.com wrote:
On Fri, Jul 29, 2011 at 10:47:43AM +0200, Jean Pihet wrote:
On Fri, Jul 29, 2011 at 9:59 AM, Todd Poynor toddpoy...@google.com wrote:
...
All min_latency != PM_QOS_DEV_LAT_DEFAULT_VALUE paths need
Todd,
On Tue, Aug 2, 2011 at 10:57 AM, Jean Pihet jean.pi...@newoldbits.com wrote:
Todd,
On Fri, Jul 29, 2011 at 10:50 AM, Jean Pihet jean.pi...@newoldbits.com
wrote:
On Fri, Jul 29, 2011 at 10:08 AM, Todd Poynor toddpoy...@google.com wrote:
On Thu, Jul 28, 2011 at 10:30:14AM +0200
Todd,
On Fri, Jul 29, 2011 at 10:50 AM, Jean Pihet jean.pi...@newoldbits.com wrote:
On Fri, Jul 29, 2011 at 10:08 AM, Todd Poynor toddpoy...@google.com wrote:
On Thu, Jul 28, 2011 at 10:30:14AM +0200, jean.pi...@newoldbits.com wrote:
...
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch
Rafael,
2011/7/30 Rafael J. Wysocki r...@sisk.pl:
On Thursday, July 28, 2011, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
Extend the PM QoS kernel API:
- add a new PM QoS class PM_QOS_DEV_LATENCY for device wake-up latency
constraints
- make the pm_qos_add_request API
Rafael,
2011/7/29 Rafael J. Wysocki r...@sisk.pl:
On Thursday, July 28, 2011, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
The PM QoS implementation files are better named
kernel/pm_qos.c and include/linux/pm_qos.h.
...
create mode 100644 include/linux/pm_qos.h
Rafael,
2011/7/31 Rafael J. Wysocki r...@sisk.pl:
On Thursday, July 28, 2011, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
Re-design the PM QoS implementation to support the per-device
constraints:
Well, I guess I should have reviewed this patch before [03/13].
Hmm
Rafael,
2011/7/31 Rafael J. Wysocki r...@sisk.pl:
On Thursday, July 28, 2011, jean.pi...@newoldbits.com wrote:
...
@@ -113,6 +109,8 @@ void device_pm_remove(struct device *dev)
{
pr_debug(PM: Removing info for %s:%s\n,
dev-bus ? dev-bus-name : No Bus, dev_name(dev));
Mark,
On Thu, Jul 28, 2011 at 3:14 PM, mark gross markgr...@thegnar.org wrote:
On Thu, Jul 28, 2011 at 10:30:07AM +0200, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
This patch set is in an RFC state, for review and comments.
High level implementation:
...
7. Misc
Todd,
On Fri, Jul 29, 2011 at 9:59 AM, Todd Poynor toddpoy...@google.com wrote:
On Thu, Jul 28, 2011 at 10:30:15AM +0200, jean.pi...@newoldbits.com wrote:
...
+int pwrdm_set_wkup_lat_constraint(struct powerdomain *pwrdm, void *cookie,
+ long min_latency)
+{
+
On Fri, Jul 29, 2011 at 10:08 AM, Todd Poynor toddpoy...@google.com wrote:
On Thu, Jul 28, 2011 at 10:30:14AM +0200, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
The powerdomains next states are initialized in pwrdms_setup as a
late_initcall. Because the PM QoS devices
From: Jean Pihet j-pi...@ti.com
This patch set is in an RFC state, for review and comments.
High level implementation:
1. Add a new PM QoS class for device wake-up constraints (PM_QOS_DEV_LATENCY).
. Define a pm_qos_constraints struct for the storage of the constraints list
and associated
From: Jean Pihet j-pi...@ti.com
The PM QoS implementation files are better named
kernel/pm_qos.c and include/linux/pm_qos.h.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-msm/clock.c |2 +-
drivers/acpi/processor_idle.c |2 +-
drivers/cpuidle/cpuidle.c
From: Jean Pihet j-pi...@ti.com
Add the field latency_constraints in the struct dev_pm_info
and the initialization of the plist in device_pm_init.
This enables the implementation of per-device constraints in
PM QoS.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
drivers/base/power/main.c |1
From: Jean Pihet j-pi...@ti.com
Extend the PM QoS kernel API:
- add a new PM QoS class PM_QOS_DEV_LATENCY for device wake-up latency
constraints
- make the pm_qos_add_request API more generic by using a parameter of
type struct pm_qos_parameters
- minor clean-ups and rename of struct fields
From: Jean Pihet j-pi...@ti.com
Re-design the PM QoS implementation to support the per-device
constraints:
- Define a pm_qos_constraints struct for the storage of the constraints
list and associated values (target_value, default_value, type ...).
- Update the pm_qos_object struct
From: Jean Pihet j-pi...@ti.com
The devices latency constraints class of PM QoS is storing the
constraints list in the device dev_pm_info struct.
This patch adds the init and de-init of the per-device constraints
list in order to support the dynamic insertion and removal
of the devices
From: Jean Pihet j-pi...@ti.com
Created arch/arm/plat-omap/omap-pm-constraints.c file from
arch/arm/plat-omap/omap-pm-noop.c and the associated Kconfig option
OMAP_PM_CONSTRAINTS.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/plat-omap/Kconfig |7 +
arch/arm/plat-omap
From: Jean Pihet j-pi...@ti.com
The powerdomains next states are initialized in pwrdms_setup as a
late_initcall. Because the PM QoS devices constraint can be requested
early in the boot sequence, the power domains next states can be
overwritten by pwrdms_setup.
This patch fixes
From: Jean Pihet j-pi...@ti.com
When a PM QoS device latency constraint is requested or removed the
PM QoS layer notifies the underlying layer with the updated aggregated
constraint value. The constraint is stored in the powerdomain constraints
list and then applied to the corresponding power
From: Jean Pihet j-pi...@ti.com
Figures are added to the power domains structs.
Note: the figures are preliminary figures. More accurate measurements
are needed. Also the conditions of measurements shall be investigated
and described.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency
wake-up latency constraints on
MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/powerdomains44xx_data.c | 84 +++
1 files changed, 84 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
b/arch/arm
From: Jean Pihet j-pi...@ti.com
Hwmod is queried from the OMAP_PM layer to manage the power domains
wake-up latency constraints. Hwmod retrieves the correct power domain
and if it exists it calls the corresponding power domain function.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF
From: Jean Pihet j-pi...@ti.com
Implement the devices wake-up latency constraints using a PM QoS
notification handler which applies the constraints to the
underlying layer by calling the corresponding function at hwmod level.
Note: the bus throughput function is implemented but currently
From: Jean Pihet j-pi...@ti.com
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_LATENCY class of the PM QoS framework
Hi,
On Fri, Jul 22, 2011 at 10:57 AM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Jul 21, 2011 at 04:52:13PM -0700, Kevin Hilman wrote:
Board code should not touch omap_device internals. To get the MPU/IVA
devices,
use existing APIs: omap2_get_mpu_device(), omap2_get_iva_device().
Hi,
On Fri, Jul 22, 2011 at 10:57 AM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Jul 21, 2011 at 04:52:13PM -0700, Kevin Hilman wrote:
Board code should not touch omap_device internals. To get the MPU/IVA
devices,
use existing APIs: omap2_get_mpu_device(), omap2_get_iva_device().
Hi Rafael,
2011/7/2 Rafael J. Wysocki r...@sisk.pl:
Hi,
On Thursday, June 30, 2011, jean.pi...@newoldbits.com wrote:
...
@@ -462,6 +463,7 @@ struct dev_pm_info {
unsigned long accounting_timestamp;
void *subsys_data; /* Owned by the subsystem. */
Hi Rafael, Mark,
- Looping in Mark for the user space API
2011/7/2 Rafael J. Wysocki r...@sisk.pl:
Hi,
On Thursday, June 30, 2011, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
- add a new PM QoS class PM_QOS_DEV_WAKEUP_LATENCY for device wake-up
constraints. Due
Hi Rafael,
2011/7/2 Rafael J. Wysocki r...@sisk.pl:
Hi,
On Thursday, June 30, 2011, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
The devices wake-up latency constraints class of PM QoS is
storing the constraints list using the device pm_info struct.
This patch adds
Hi Rafael,
2011/7/2 Rafael J. Wysocki r...@sisk.pl:
Hi,
On Thursday, June 30, 2011, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
This patch set is in an RFC state, for review and comments.
First off, I'm sorry I couldn't review the patchset earlier.
Thank you very much
Hi Mark,
On Mon, Jun 27, 2011 at 3:40 PM, mark gross markgr...@thegnar.org wrote:
On Fri, Jun 24, 2011 at 04:37:57PM +0200, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
This patch set is in an RFC state, for review and comments.
In order to implement the new class in PM
On Mon, Jun 27, 2011 at 8:33 PM, Todd Poynor toddpoy...@google.com wrote:
On Fri, Jun 24, 2011 at 04:38:05PM +0200, jean.pi...@newoldbits.com wrote:
...
+ /* Find the associated omap_device for dev */
+ od = container_of(pdev, struct omap_device, pdev);
+ if (!od || (od-hwmods_cnt
From: Jean Pihet j-pi...@ti.com
Add the field wakeup_lat_plist_head in the struct dev_pm_info
and the initialization of the plist in device_pm_init.
This enables the implementation of per-device constraints in
PM QoS.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
drivers/base/power/main.c
From: Jean Pihet j-pi...@ti.com
The devices wake-up latency constraints class of PM QoS is
storing the constraints list using the device pm_info struct.
This patch adds the init and de-init of the per-device constraints
list in order to support the dynamic insertion and removal
of the devices
From: Jean Pihet j-pi...@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
From: Jean Pihet j-pi...@ti.com
Created arch/arm/plat-omap/omap-pm-constraints.c file from
arch/arm/plat-omap/omap-pm-noop.c and the associated Kconfig option
OMAP_PM_CONSTRAINTS.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/plat-omap/Kconfig |7 +
arch/arm/plat-omap
From: Jean Pihet j-pi...@ti.com
When a wake-up latency constraint is requested or removed the PM QoS
layer notifies the underlying layer with the updated strongest constraint
value. The constraint is stored in the powerdomain constraints list
and then applied to the corresponding power domain
wake-up latency constraints on
MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/powerdomains44xx_data.c | 85 +++
1 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
b/arch/arm
From: Jean Pihet j-pi...@ti.com
Hwmod is queried from the OMAP_PM layer to manage the power domains
wake-up latency constraints. Hwmod retrieves the correct power domain
and if it exists it calls the corresponding power domain function.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF
From: Jean Pihet j-pi...@ti.com
Implement the devices wake-up latency constraints using a PM QoS
notification handler which applies the constraints to the
underlying layer by calling the corresponding function at hwmod level.
Note: the bus throughput function is implemented but currently
From: Jean Pihet j-pi...@ti.com
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
From: Jean Pihet j-pi...@ti.com
Most of the ASM sleep code (in arch/arm/mach-omap2/sleep34xx.S)
is copied to internal SRAM at boot and after wake-up from CORE OFF mode.
However only a small part of the code really needs to run from internal SRAM.
This fix lets most of the ASM idle code run from
On Wed, Jun 29, 2011 at 7:29 PM, Kevin Hilman khil...@ti.com wrote:
jean.pi...@newoldbits.com writes:
From: Jean Pihet j-pi...@ti.com
Most of the ASM sleep code (in arch/arm/mach-omap2/sleep34xx.S)
is copied to internal SRAM at boot and after wake-up from CORE OFF mode.
However only a small
Hi Santosh,
On Sat, Jun 25, 2011 at 3:23 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On 6/24/2011 7:38 AM, jean.pi...@newoldbits.com wrote:
From: Jean Pihetj-pi...@ti.com
Since cpuidle is a CPU centric framework it decides the MPU
next power state based on the MPU exit_latency and
Santosh,
On Mon, Jun 27, 2011 at 4:11 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On 6/26/2011 11:53 PM, Jean Pihet wrote:
Hi Santosh,
On Sat, Jun 25, 2011 at 3:23 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On 6/24/2011 7:38 AM, jean.pi...@newoldbits.com wrote
Russell,
Just a minor remark:
On Thu, Jun 23, 2011 at 9:16 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
Convert sa11x0 to use the generic CPU suspend/resume support, rather
^^^ should be 'OMAP3'
than implementing its own version. Tested on 3430 LDP.
(SA1100) and 3430LDP only.
That is a great set of patches! We are now close to have a clean
suspend code, all the way from arch code to low level OMAP-specific
ASM implementation.
FWIW:
Acked-by: Jean Pihet j-pi...@ti.com
Regards,
Jean
arch/arm/include/asm/suspend.h | 21
arch/arm
entry points for these
functions, and uses those values directly when writing the scratchpad.
Tested all three entry points
- restore_es3: 3430/n900
- restore_3630: 3630/Zoom3
- restore: 3530/Overo
Suggested-by: Russell King rmk+ker...@arm.linux.org.uk
Cc: Jean Pihet jean.pi
Hi Kevin,
On Fri, Jun 24, 2011 at 2:17 AM, Kevin Hilman khil...@ti.com wrote:
Hi Jean,
Can you rebase/retest this on top of my pm-wip/idle-suspend branch,
which now contains Russell's major cleanup to use the common code as
well as an additional patch from me to remove the unncessary
From: Jean Pihet j-pi...@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
From: Jean Pihet j-pi...@ti.com
Add the field wakeup_lat_plist_head in the struct dev_pm_info
and the initialization of the plist in device_pm_init.
This enables the implementation of per-device constraints in
PM QoS.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
drivers/base/power/main.c
From: Jean Pihet j-pi...@ti.com
- add a new PM QoS class PM_QOS_DEV_WAKEUP_LATENCY for device wake-up
constraints. Due to the per-device nature of the new class the constraints
list is stored inside the device dev_pm_info struct instead of the internal
per-class constraints lists.
The new class
From: Jean Pihet j-pi...@ti.com
Created arch/arm/plat-omap/omap-pm-constraints.c file from
arch/arm/plat-omap/omap-pm-noop.c and the associated Kconfig option
OMAP_PM_CONSTRAINTS.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/plat-omap/Kconfig |7 +
arch/arm/plat-omap
From: Jean Pihet j-pi...@ti.com
Figures are added to the power domains structs.
Note: the figures are preliminary figures. More accurate measurements
are needed. Also the conditions of measurements shall be investigated
and described.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency
wake-up latency constraints on
MPU, CORE and PER.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/powerdomains44xx_data.c | 85 +++
1 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
b/arch/arm
From: Jean Pihet j-pi...@ti.com
Hwmod is queried from the OMAP_PM layer to manage the power domains
wake-up latency constraints. Hwmod retrieves the correct power domain
and if it exists it calls the corresponding power domain function.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF
From: Jean Pihet j-pi...@ti.com
Implement the devices wake-up latency constraints using a PM QoS
notification handler which applies the constraints to the
underlying layer by calling the corresponding function at hwmod level.
Note: the bus throughput function is implemented but currently
From: Jean Pihet j-pi...@ti.com
When a wake-up latency constraint is requested or removed the PM QoS
layer notifies the underlying layer with the updated strongest constraint
value. The constraint is stored in the powerdomain constraints list
and then applied to the corresponding power domain
From: Jean Pihet j-pi...@ti.com
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
From: Jean Pihet j-pi...@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
Hi Paul,
On Fri, 6 May 2011, Jean Pihet wrote:
I checked the patch against the master branch of both Tony's and
Linus's trees, it applies and compiles OK.
Is that OK to you?
If it applies cleanly against Linus's current tree, then yes, that's fine.
Do you know what happened to this patch
From: Jean Pihet j-pi...@ti.com
Most of the ASM sleep code (in arch/arm/mach-omap2/sleep34xx.S)
is copied to internal SRAM and run from there.
However only a small part of the code really needs to run from internal SRAM.
This fix lets most of the ASM idle code run from the DDR
in order
501 - 600 of 931 matches
Mail list logo
