SRF Replacement - Constraints Part

From OMAPpedia

Revision as of 10:15, 7 July 2010

Introduction

This wikipage describes the efforts of replacing constraints part of the Shared Resource Framework (SRF).

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
  • Any driver can place constraints
  • Designed for existing omap-pm 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 (multiple step lookup as starting  with general device)
	2. Use device pointer as identifier for constraint request

	if (t == -1)
		pwrdm_wakeuplat_release_constraint(pwrdm, dev);
	else
		pwrdm_wakeuplat_set_constraint (pwrdm, dev, t);
}

• Power domain layer – constraint enforcement/ tracking implemented here
  • State change happens by programming next state
  • If device is already in low power state, do a wakeup before 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 wakeuplat[NUM_FUNC_PWRST];
static LIST_HEAD(wakeup_lat_constraint_list);
} 
static struct powerdomain core_44xx_pwrdm = {
.wakeuplat = {
  [FUNC_PWRST_OFF] = 50,
  [FUNC_PWRST_OSWR] = 30,
  [FUNC_PWRST_CSWR] = 5,
  [FUNC_PWRST_ON] = 0,
 };
}

• 3 Scenarios: new constraint, update old constraint, or release it

pwrdm_wakeuplat_set_constraint (struct powerdomain *pwrdm, stuct device *dev, 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_wakeuplat_release_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_wakeuplat_update_pwrst (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
	
	3.  if (pwrdm->state != new_state)
 		    pwrdm_set_next_pwrst (pwrdm, new_state); // existing function to program next state
}

Implementation Schedule

Post PM Workshop Deliverables for SRF Replacement - Constraints Part