Proceedings of the PM SW Workshop Jun 2010

From OMAPpedia

(Difference between revisions)
Jump to: navigation, search
(Minutes & Action Items)
 
(28 intermediate revisions not shown)
Line 56: Line 56:
* More to be added as identified during discussions
* More to be added as identified during discussions
-
===Minutes===
+
===Minutes & Action Items===
* Aligned on all the discussions and PPT presented by Benoit & Rajendra
* Aligned on all the discussions and PPT presented by Benoit & Rajendra
* Aligned on Latency measurements; need to identify the resources to do it  
* Aligned on Latency measurements; need to identify the resources to do it  
Line 82: Line 82:
Aligned on the following two phase approach  
Aligned on the following two phase approach  
* '''Phase 1 '''
* '''Phase 1 '''
-
** Clean up instances of usage of PRM/ CM APIs outside power domain & clock domain. Move these instances to appropriate frameworks.   
+
** Clean up instances of usage of PRM/ CM APIs outside power domain & clock domain frameworks. Move these instances to appropriate frameworks.   
** This work can go ahead – there is enough clarity.
** This work can go ahead – there is enough clarity.
-
** Need to figure out how to handle PRM FSM in some of the APIs - '''Rajendra, Benoit & Paul'''
+
** Need to figure out how to handle PRM FSM in some of the APIs - '''Rajendra & Benoit'''
* '''Phase 2'''
* '''Phase 2'''
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==
==SRF Replacement - Constraints Part==
Line 119: Line 118:
===Proposed Implementation===
===Proposed Implementation===
-
* OMAP PM layer - API’s exported to driver are defined here
+
* '''OMAP PM layer - API’s exported to driver are defined here'''
-
* Are all drivers going to be of type omap_device?
+
** Are all drivers going to be of type omap_device?
-
* Design for existing omap-pm vs. omap_device layer?
+
** Design for existing omap-pm vs. omap_device layer?
-
* -1 to release constraint, otherwise 0 or higher (acceptable latency in us)
+
** -1 to release constraint, otherwise 0 or higher (acceptable latency in us)
-
* We can’t assume that only releasing the constraint will lower power
+
** We can’t assume that only releasing the constraint will lower power
-
* Lowering the constraint can still trigger power state change   
+
** 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);
 +
}
 +
 
 +
* '''Power domain layer – constraint enforcement/ tracking implemented here'''
 +
** How does the state change happen? Just by programming next state?
 +
** powerdomain struct extended to capture following:
 +
*** Power domain’s wakeup latency for each supported power state
 +
*** List header for wakeup latency constraint placed by all devices in this domain; can be defined in powerdomains44
 +
struct powerdomain {
 +
/* existing entries*/
 +
const u32 wakeup_lat[PWRDM_MAX_PWRSTS-1];
 +
static LIST_HEAD(wakeup_lat_constraint_list);
 +
}
 +
static struct powerdomain core_44xx_pwrdm = {
 +
.wakeup_lat = {
 +
50,  /* off */
 +
20,  /* ret */ -1 for not supported power state
 +
0,    /* inactive */ Do we have to worry about OSWR?
 +
}
 +
}
 +
 
 +
* '''3 Scenarios: new constraint, update old constraint, or release it'''
 +
pwrdm_set_wakeup_lat_constraint (struct powerdomain *pwrdm, char *lat_dev_name, long lat_us){
 +
1. If new constraint, add a new entry to wakeup_lat_constraint_list
 +
2. If already existing, update entries’ latency value
 +
3. pwrdm_check_for_state_change (pwrdm)
 +
}
 +
pwrdm_release_wakeup_lat_constraint (struct powerdomain *pwrdm, char  *lat_dev_name){
 +
1. Remove this devices’ constraint from wakeup_lat_constraint_list
 +
2. pwrdm_check_for_state_change (pwrdm)
 +
}
 +
pwrdm_check_for_state_change (struct powerdomain *pwrdm){
 +
1. min_latency = find_min_wakeup_latency_constraint (pwrdm)
 +
//go through the list for minimum latency value
 +
2. find power state that has latency lower than minimum constraint
 +
for (new_state = 0x0; new_state < PWRDM_MAX_PWRSTS; new_state++){
 +
    if (pwrdm->wakeup_lat[i] < min_latency) break;
 +
}
 +
3.  if (pwrdm->state != new_state)
 +
      pwrdm_set_next_pwrst (pwrdm, new_state); // existing function to program next state
 +
}
 +
 
 +
===Minutes & Action Items===
 +
* Use device wakeup latency instead of device latency.
 +
* Need to start pursuing the HW team to provide wakeup latency numbers – this is a very much needed in the long run; and it is needed for complete entitlement of HW PM features by the SW
 +
* Aligned on Vibhore’s proposal + comments provided during the meeting (e.g. structures suggested by Paul during meeting); Vibhore can go ahead with the implementation
 +
 
 +
.wakeuplat = {
 +
    [FUNC-PWRST-OFF] = 50,
 +
    [FUNC-PWRST-OSWR] = 30,
 +
  [FUNC-PWRST-CSWR] = 5,
 +
  [FUNC-PWRST-ON] = 0,
 +
};
 +
.func_pwrsts = (FUNC_PWRST_OFF | FUNC_PWRST_OSWR | FUNC_PWRST_CSWR |  FUNC_PWRST_ON)
 +
1 << FUNC_PWRST_OFF
 +
pwrdm_wakelat_set_constraint
 +
pwrdm_wakeuplat_remove_constraint
 +
pwrdm_wakeuplat_update_pwrst)
 +
 
 +
* The open question is how we measure the latencies and who will do it.
 +
 +
 
 +
==SRF Replacement - OPP Part==
 +
Aligned on using device based OPP approach & maintaining constraints in voltage layer for OPP part of SRF replacement. Sufficient details have been worked out to proceed with the basic DVFS implementation of VDD MPU, VDD IVA & VDD Core voltage domains.
 +
 
 +
===RFC Patches===
 +
Here is a work-in-progress patch that shows work done so far and some of the review comments addressed. Please note that this is in no way completed, compiling, clean patch. It is provided to have a better idea of the changes proposed and discussed.
 +
 
 +
[[File: SRF_Replacement_OPP_Part_RFC_Patch.pdf]]
 +
 
 +
===Minutes & Action Items===
 +
* '''Attaining VDD MPU, VDD IVA & VDD Core DVFS basic functionality'''
 +
** Shift in approach from voltage domain based OPP to device based OPP
 +
*** OPP will be stored in separate SOC dependent file from other clock, hwmod, voltage files.
 +
*** These will be loaded into memory and then board-specific modifications will be done.
 +
*** The device HWMODs will point to the dynamic versions of the device-OPPs.
 +
** Kevin is targeting it for the next merge window – should be doable by month end but needs Thara’s full bandwidth
 +
** Kevin will do the data structural changes and get them working with existing SRF – '''Kevin''' (initial version posted: 16 June)
 +
** Then '''Thara''' will take it and remove the SRF.
 +
** Then '''Thara''' will implement the new APIs for DVFS & omap device layer viz. omap_device_set_min_rate(hwmod, rate) & omap_device_get_cur_rate(dev) These internally will call set_rate() & get_rate() of the HWMOD.
 +
** Once VDD Core OPP changes, the changing of scalable functional clocks (for affected IPs as per the Excel sheet) will be done by HWMOD function implementations.
 +
** The final part will be to extend the voltage layer to take care of constraints and cross VDD dependencies (they are there in OMAP3 code but needs to be transformed to the new format)
 +
*** Kevin suggested to use plist (priority assigned doubly linked lists) for this purpose
 +
 
 +
* '''Enhancement to allow drivers to block or allow rate change of their scalable clocks '''
 +
** The following APIs need to be added to the clock framework to allow drivers to block or allow rate change of their scalable clocks (& their parents)
 +
** The APIs are clock_block_change(), clock_allow_change(), is_clock_rate_change_allowed() – '''Paul''' is OK if some one also picks up this.
 +
** Need to ensure that the implementation doesn’t result into race conditions
 +
** This is needed for OMAP4 VDD Core DVFS implementation for handling of corner cases. E.g. if a driver doesn’t want to allow functional or optional clock change. Today’s SRF doesn’t support this and there are no major issues with it.
 +
 
 +
==Review of Device Driver HWMOD Adaptations==
 +
===MUSB===
 +
* MUSB team to investigate whether omap_device_enable_wakeup() and omap_device_disable_wakeup() functions need to be added to take care of an errata
 +
** Current user of this will be MUSB but in future other drivers can also use this
 +
 
 +
===MMC===
 +
* Can Suspend & Runtime Suspend implementations be made common? This will lead to early suspend from the drivers. - '''MMC team''' to explore this option
 +
 
 +
 
 +
===DSS===
 +
* Using detailed DSS sub-module specific hwmod requires imeplementing dispc_device-dispc_driver, dsi_driver, dsi_device-dsi_driver as platform_devices - '''Senthil to plan'''
 +
* Follow-up discussion on this with Tomi needed for finalizing on the design - '''Senthil'''
 +
* Check if the DSS DPLLs are same as that of the main OMAP3,4 dplls.          This will aid in the decision of if Clock-FW could also address DSS DPLLs. - '''Senthil'''
 +
 
-
void omap_pm_set_max_dev_wakeup_lat(struct device *dev, long t)
+
===DMA===
-
{
+
* '''Manjunath''' to add the HWMOD data first before doing the registration.
-
/* existing code */
+
* '''Manjunath''' to add Channel count etc in dev_attr.
-
1. Look for devices’ power domain (might be multiple step if starting with general device)
+
* '''Manjunath''' to move DMA implementation into device drivers & have exported APIs. One more reason is to have a generic driver hiding SDMA & EDMA under the hood.
-
2. Use device name as identifier for constraint request
+
** '''Manjunath''' to do the platform device conversion.
 +
** '''Manjunath''' to do HWMOD changes
 +
** '''Manjunath''' to do the conversion into plat-omap & mach-omap layers getting rid of cpuxx checks.
 +
** '''Manjunath''' to move plat-omap to driver layer
 +
** Next step could be to implement Async Tx DMA support.
 +
* '''Manjunath & Santosh''' to align with the DMA maintainer (dan.j.williams@intel.com)
-
if (t == -1)
+
==General Minutes and Action Items==
-
pwrdm_release_wakeup_lat_constraint (pwrdm, lat_dev_name);
+
* All hwmods need to be tested only through run-time PM.
-
else
+
** This is true for all other drivers.
-
pwrdm_set_wakeup_lat_constraint (pwrdm, lat_dev_name, t);
+
** If CONFIG_RUNTIME_PM is not enabled, hw-mod initialization should keep the clocks turned-on.
-
}
+
* Review all h/w-attrs and segregate into Class specific dev-attrs is appropriate.
 +
* All HWMOD data should not be introduced in one-shot. HWMOD database for a particular device should be introduced incrementally as the driver gets modified and tested.
 +
* SmartReflex should be targeted for the Aug end merge window.
 +
* There is need to have more meetings between maintainers (Paul, Kevin, Tony) and the key HW IP designers for the following reasons
 +
** For HW designers to understand how “hacks” or “one of cases” negatively impact Linux SW design (making it complex and difficult to manage)
 +
** For maintainers to better understand constraints of HW design so that they can suggest a better SW modeling solution

Latest revision as of 00:20, 17 June 2010

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

Contents

[edit] HWMOD Framework Enhancements

[edit] Reset Management Support in HWMOD

[edit] More Granular HWMOD Structures

[edit] Multi-level omap_device_idle

Placeholder for patches from Vibhore to support device latency contraint

[edit] Access to HWMOD Internal Data

[edit] Miscellaneous Issues

[edit] Minutes & Action Items


[edit] Power Domain And Clock Domain Cleanup

Aligned on the following two phase approach

[edit] SRF Replacement - Constraints Part

[edit] Types of Latency Constraints

[edit] Details of Interrupt Latency

[edit] Details of Device Latency

[edit] 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);
}
struct powerdomain {
/* existing entries*/
const u32 wakeup_lat[PWRDM_MAX_PWRSTS-1];
static LIST_HEAD(wakeup_lat_constraint_list);
} 
static struct powerdomain core_44xx_pwrdm = {
.wakeup_lat = {
50,   /* off */
20,   /* ret */ -1 for not supported power state
0,     /* inactive */ Do we have to worry about OSWR?
}
}
pwrdm_set_wakeup_lat_constraint (struct powerdomain *pwrdm, char *lat_dev_name, long lat_us){
	1. If new constraint, add a new entry to wakeup_lat_constraint_list
	2. If already existing, update entries’ latency value
	3. pwrdm_check_for_state_change (pwrdm)
} 
pwrdm_release_wakeup_lat_constraint (struct powerdomain *pwrdm, char   *lat_dev_name){
	1. Remove this devices’ constraint from wakeup_lat_constraint_list
	2. pwrdm_check_for_state_change (pwrdm)
}
pwrdm_check_for_state_change (struct powerdomain *pwrdm){
	1. min_latency = find_min_wakeup_latency_constraint (pwrdm) 
		 //go through the list for minimum latency value
	2. find power state that has latency lower than minimum constraint
		 for (new_state = 0x0; new_state < PWRDM_MAX_PWRSTS; new_state++){
		    if (pwrdm->wakeup_lat[i] < min_latency) break;
		}
	3.  if (pwrdm->state != new_state)
 		    pwrdm_set_next_pwrst (pwrdm, new_state); // existing function to program next state
}

[edit] Minutes & Action Items

.wakeuplat = {
    [FUNC-PWRST-OFF] = 50,
   [FUNC-PWRST-OSWR] = 30,
  [FUNC-PWRST-CSWR] = 5,
  [FUNC-PWRST-ON] = 0,
};
.func_pwrsts = (FUNC_PWRST_OFF | FUNC_PWRST_OSWR | FUNC_PWRST_CSWR |   FUNC_PWRST_ON)
1 << FUNC_PWRST_OFF
pwrdm_wakelat_set_constraint
pwrdm_wakeuplat_remove_constraint
pwrdm_wakeuplat_update_pwrst)


[edit] SRF Replacement - OPP Part

Aligned on using device based OPP approach & maintaining constraints in voltage layer for OPP part of SRF replacement. Sufficient details have been worked out to proceed with the basic DVFS implementation of VDD MPU, VDD IVA & VDD Core voltage domains.

[edit] RFC Patches

Here is a work-in-progress patch that shows work done so far and some of the review comments addressed. Please note that this is in no way completed, compiling, clean patch. It is provided to have a better idea of the changes proposed and discussed.

File:SRF Replacement OPP Part RFC Patch.pdf

[edit] Minutes & Action Items

[edit] Review of Device Driver HWMOD Adaptations

[edit] MUSB

[edit] MMC


[edit] DSS


[edit] DMA

[edit] General Minutes and Action Items

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox