Proceedings of the PM SW Workshop Jun 2010

From OMAPpedia

(Difference between revisions)
Jump to: navigation, search
(Minutes & Action Items)
(Minutes & Action Items)
 
(6 intermediate revisions not shown)
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 198: Line 197:
==SRF Replacement - OPP Part==
==SRF Replacement - OPP Part==
-
Aligned on using device based OPP approach & maintaining constraints in voltage layer for OPP part of SRF replacement.  
+
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===
===RFC Patches===
Line 212: Line 211:
*** The device HWMODs will point to the dynamic versions of the device-OPPs.
*** 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 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''' by Tuesday 15-Jun
+
** 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 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.  
** 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.  
Line 227: Line 226:
==Review of Device Driver HWMOD Adaptations==
==Review of Device Driver HWMOD Adaptations==
===MUSB===
===MUSB===
-
* Paul will provide omap_device_enable_wakeup() and omap_device_disable_wakeup() functions  
+
* 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
-
** These are needed to take care of an errata
+
** Current user of this will be MUSB but in future other drivers can also use this
-
** Current user of this will be MUSB but in future other drivers can also use this  
+
-
 
+
===MMC===
===MMC===
Line 243: Line 240:
===DMA===
===DMA===
-
* Add the HWMOD data first before doing the registration.
+
* '''Manjunath''' to add the HWMOD data first before doing the registration.
-
* Add Channel count etc in dev_attr.
+
* '''Manjunath''' to add Channel count etc in dev_attr.
-
* In dma_system_irqa==>change macro to names. If a change breaks other drivers, change needs to be done here.
+
* '''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.
-
* Move DMA implementation into device drivers & have exported APIs. . One more reason is to have a generic driver hiding SDMA & EDMA under the hood.
+
** '''Manjunath''' to do the platform device conversion.
-
** Convert into a platform device.
+
** '''Manjunath''' to do HWMOD changes
-
** HWMOD changes
+
** '''Manjunath''' to do the conversion into plat-omap & mach-omap layers getting rid of cpuxx checks.
-
** Convert into plat-omap & mach-omap layers getting rid of cpuxx checks.
+
** '''Manjunath''' to move plat-omap to driver layer
-
** Move plat-omap to driver layer
+
** Next step could be to implement Async Tx DMA support.
** Next step could be to implement Async Tx DMA support.
-
* Align with the DMA maintainer (dan.j.williams@intel.com)
+
* '''Manjunath & Santosh''' to align with the DMA maintainer (dan.j.williams@intel.com)
-
 
+
==General Minutes and Action Items==
==General Minutes and Action Items==

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