Proceedings of the PM SW Workshop Jun 2010

From OMAPpedia

(Difference between revisions)
Jump to: navigation, search
(Minutes & Action Items)
 
(31 intermediate revisions not shown)
Line 52: Line 52:
===Miscellaneous Issues===
===Miscellaneous Issues===
-
* Today omap_device_build provides a way to only pass platform_data structure during device registration.  
+
* Today omap_device_build provides a way to only pass platform_data structure during device registration. How do you pass other info which needs to be part of struct device? E.g. in the case of USB driver, there is a need to populate the dma_mask.  
-
* How do you pass other info which needs to be part of struct device? E.g. in the case of USB driver, there is a need to populate the dma_mask.  
+
* Is usecounting needed at omap_device level?
* Is usecounting needed at omap_device level?
* 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 78: Line 77:
** Fix OMAP4 hwmod generator to generate HWMOD_NO_IDLEST '''Partha'''
** Fix OMAP4 hwmod generator to generate HWMOD_NO_IDLEST '''Partha'''
** Remove OCP_USER from OMAP4 hwmods without address space: OMAP4 autogen '''Partha'''
** Remove OCP_USER from OMAP4 hwmods without address space: OMAP4 autogen '''Partha'''
 +
 +
 +
==Power Domain And Clock Domain Cleanup==
 +
Aligned on the following two phase approach
 +
* '''Phase 1 '''
 +
** 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.
 +
** Need to figure out how to handle PRM FSM in some of the APIs - '''Rajendra & Benoit'''
 +
 +
* '''Phase 2'''
 +
** Split the power domain and clock domain framework into platform and platform independent parts
 +
** Adopt the approach of doing the changes first and then moving 
 +
** 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);
 +
}
 +
 +
* '''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'''
 +
 +
 +
===DMA===
 +
* '''Manjunath''' to add the HWMOD data first before doing the registration.
 +
* '''Manjunath''' to add Channel count etc in dev_attr.
 +
* '''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.
 +
** '''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)
 +
 +
==General Minutes and Action Items==
 +
* 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.
 +
* 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