Proceedings of the PM SW Workshop Jun 2010

From OMAPpedia

(Difference between revisions)
Jump to: navigation, search
Line 90: Line 90:
** Adopt the approach of doing the changes first and then moving   
** Adopt the approach of doing the changes first and then moving   
** Some work has been done by Abhijit but need more discussions
** Some work has been done by Abhijit but need more discussions
 +
 +
 +
==SRF Replacement - Constraints Part==
 +
===Types of Latency Constraints===
 +
* '''Interrupt latency or System latency'''
 +
** This is the total amount of time taken once an interrupt occurs to the time the interrupt handler is scheduled.
 +
** Depends mainly on the system sleep state or C state.
 +
** Since different C states take different amount of time to wakeup, the interrupt/ system latency constraint actually governs the deepest C state acceptable to the system at any given time.
 +
 +
* '''Device latency constraint'''
 +
** This is the total amount of time taken for a device to become accessible.
 +
** It includes turning the clocks on, bringing the clockdomain out of inactive, power domain out of RET or OFF (with context restore) state.
 +
** This constraint mainly governs the deepest device idle state (only clocks cut, clockdomain in inactive, Powerdomain in RET or off) acceptable to the device at any given time.
 +
 +
===Details of Interrupt Latency===
 +
* pm_qos framework (kernel/pm_qos_params.c) already has support for CPU_DMA_LATENCY
 +
* The CPUidle menu governor also looks at CPU_DMA_LATENCY before deciding on the target C state
 +
* The omap-pm apis (omap_pm_set_max_mpu_wakeup_lat and omap_pm_set_max_sdma_lat) and be used to internally update the pm-qos framework which already does use-counting.
 +
* Something like a pdev->name can be used to identify the device putting the constraint.
 +
 +
===Details of Device Latency===
 +
* When a device is ready to idle, it calls the omap_device_idle api. Today, this turns the clocks off and eventually the clockdomain/powerdomains transition to the respective states.
 +
* Without any device latency constraints in place a device calling omap_device_idle could hit a OFF state.
 +
* The initial proposal is to map device states to various powerdomain states supported.
 +
* The omap-pm api (omap_pm_set_max_dev_wakeup_lat) called by the device will map to a given powerdomain state acceptable to the device.
 +
* This can be implemented by extending the current powerdomain framework to keep track of all the devices in the domain and their acceptable latencies. For each powerdomain, latency information for each state supported will also be needed.
 +
* Implementing the api will involve identifying the powrdomain the device belongs to, determining the lowest acceptable latency among *all* other devices in the powerdomain and then mapping the latency to the target powerdomain state.
 +
 +
===Proposed Implementation===
 +
* OMAP PM layer - API’s exported to driver are defined here
 +
* Are all drivers going to be of type omap_device?
 +
* Design for existing omap-pm vs. omap_device layer?
 +
* -1 to release constraint, otherwise 0 or higher (acceptable latency in us)
 +
* We can’t assume that only releasing the constraint will lower power
 +
* Lowering the constraint can still trigger power state change 
 +
 +
void omap_pm_set_max_dev_wakeup_lat(struct device *dev, long t)
 +
{
 +
/*  existing code */
 +
1. Look for devices’ power domain (might be multiple step if starting with general device)
 +
2. Use device name as identifier for constraint request
 +
 +
if (t == -1)
 +
pwrdm_release_wakeup_lat_constraint (pwrdm, lat_dev_name);
 +
else
 +
pwrdm_set_wakeup_lat_constraint (pwrdm, lat_dev_name, t);
 +
}

Revision as of 10:07, 11 June 2010

This wikipage contains proceedings of the PM SW Workshop held in Bangalore on 7-11 Jun, 2010

Contents

HWMOD Framework Enhancements

Reset Management Support in HWMOD

More Granular HWMOD Structures

Multi-level omap_device_idle

Placeholder for patches from Vibhore to support device latency contraint

Access to HWMOD Internal Data

Miscellaneous Issues

Minutes


Power Domain And Clock Domain Cleanup

Aligned on the following two phase approach


SRF Replacement - Constraints Part

Types of Latency Constraints

Details of Interrupt Latency

Details of Device Latency

Proposed Implementation

void omap_pm_set_max_dev_wakeup_lat(struct device *dev, long t) { /* existing code */ 1. Look for devices’ power domain (might be multiple step if starting with general device) 2. Use device name as identifier for constraint request

if (t == -1) pwrdm_release_wakeup_lat_constraint (pwrdm, lat_dev_name); else pwrdm_set_wakeup_lat_constraint (pwrdm, lat_dev_name, t); }

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox