Proceedings of the PM SW Workshop Jun 2010

From OMAPpedia

(Difference between revisions)
Jump to: navigation, search
Line 199: Line 199:
==SRF Replacement - OPP Part==
==SRF Replacement - OPP Part==
===Minutes & Action Items===
===Minutes & Action Items===
-
* Three APIs will be added to the clock framework. This will allow drivers to block or allow rate change of their functional or optional clock
+
* '''VDD MPU, VDD IVA & VDD Core DVFS basic functionality'''
-
* The APIs are clock_block_change(), clock_allow_change(), is_clock_rate_change_allowed() – Paul is OK if some one also picks up this
+
-
* Anand to check if Thomas or Jean can take it up
+
-
* Need to ensure that the implementation doesn’t result into race conditions
+
-
* This is needed for OMAP4 VDD Core DVFS implementation but for more for accuracy, especially if a driver doesn’t want to allow functional or optional clock change. Today’s SRF doesn’t support this and we are OK with it.
+
-
* Thara can work on the rest of the VDD Core implementation. 
+
-
* 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.
+
-
* SmartReflex should be targeted for the Aug end merge window.
+
-
* VDD MPU, VDD IVA & VDD Core DVFS basic functionality  
+
** Shift in approach from voltage domain based OPP to device based OPP
** Shift in approach from voltage domain based OPP to device based OPP
-
** Kevin is targeting it for the next merge window. Should be doable by month end but needs Thara’s full bandwidth  
+
*** OPP will be stored in separate SOC dependent file from other clock, hwmod, voltage files.
-
*** Kevin will do the data structural changes and get them working with existing SRF – Kevin by Tuesday 15-Jun
+
*** These will be loaded into memory and then board-specific modifications will be done.
-
*** Then Thara can take it and remove the SRF  
+
*** The device HWMODs will point to the dynamic versions of the devie-OPPs.
-
** Implement the new APIs for DVFS & omap device layer
+
** Kevin is targeting it for the next merge window – should be doable by month end but needs Thara’s full bandwidth  
-
*** Omap_device_set_min_rate(), omap_device_get_curr_rate(),
+
** Kevin will do the data structural changes and get them working with existing SRF – '''Kevin''' by Tuesday 15-Jun
-
** 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)
+
** Then Thara will take it and remove the SRF.
-
*** We need to discuss this in more details  
+
** 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)
 +
*** This needs to be discussed in more details  
*** Kevin suggested to use plist (priority assigned doubly linked lists) for this purpose  
*** Kevin suggested to use plist (priority assigned doubly linked lists) for this purpose  
 +
 +
 +
* '''APIs to be added to the clock framework'''
 +
** This will allow drivers to block or allow rate change of their functional or optional clock
 +
** The APIs are clock_block_change(), clock_allow_change(), is_clock_rate_change_allowed() – '''Paul''' is OK if some one also picks up this. '''Anand''' to check if Thomas or Jean can take it up.
 +
** Need to ensure that the implementation doesn’t result into race conditions
 +
** This is needed for OMAP4 VDD Core DVFS implementation but for more for accuracy, especially if a driver doesn’t want to allow functional or optional clock change. Today’s SRF doesn’t support this and we are OK with it.
==General Minutes and Action Items==
==General Minutes and Action Items==
* There is need to have more meetings between maintainers (Paul, Kevin, Tony) and the key HW IP designers for the following reasons
* There is need to have more meetings between maintainers (Paul, Kevin, Tony) and the key HW IP designers for the following reasons
 +
* SmartReflex should be targeted for the Aug end merge window.
** For HW designers to understand how “hacks” or “one of cases” negatively impact Linux SW design (making it complex and difficult to manage)
** 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
** For maintainers to better understand constraints of HW design so that they can suggest a better SW modeling solution

Revision as of 11:34, 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 & Action Items


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);
}
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
}

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)


SRF Replacement - OPP Part

Minutes & Action Items



General Minutes and Action Items

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox