Proceedings of the PM SW Workshop Jun 2010

From OMAPpedia

(Difference between revisions)
Jump to: navigation, search
Line 206: Line 206:
** 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''' by Tuesday 15-Jun
-
** 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.  
** 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.  
** 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)
** 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)
Line 219: Line 219:
** Need to ensure that the implementation doesn’t result into race conditions  
** 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.  
** 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.  
 +
 +
 +
==Review of Device Driver HWMOD Adaptations==
 +
===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'''
 +
 +
 +
===DMA===
 +
* Add the HWMOD data first before doing the registration.
 +
* 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.
 +
* Move DMA implementation into device drivers & have exported APIs. . One more reason is to have a generic driver hiding SDMA & EDMA under the hood.
 +
** Convert into a platform device.
 +
** HWMOD changes
 +
** Convert into plat-omap & mach-omap layers getting rid of cpuxx checks.
 +
** Move plat-omap to driver layer
 +
** Next step could be to implement Async Tx DMA support.
 +
* Align with the DMA maintainer (dan.j.williams@intel.com)
==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
+
* All hwmods need to be tested only through run-time PM.
 +
** This is true for all other drivers.
 +
** 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.  
* 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 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
-
* Must attend conferences  
+
* Strongly recommended conferences for key TI developers
** ELC in April   
** ELC in April   
** ELC Europe in fall
** ELC Europe in fall

Revision as of 11:48, 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



Review of Device Driver HWMOD Adaptations

MMC


DSS


DMA


General Minutes and Action Items

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox