SRF Replacement - Constraints Part

From OMAPpedia

(Difference between revisions)
Jump to: navigation, search
(Proposed Implementation)
(Implementation Schedule)
 
(16 intermediate revisions not shown)
Line 2: Line 2:
This wikipage describes the efforts of replacing constraints part of the Shared Resource Framework (SRF).
This wikipage describes the efforts of replacing constraints part of the Shared Resource Framework (SRF).
 +
Here is an overview presentation: [[File: Latency_constraint_summary.ppt]]
==SRF Replacement - Constraints Part==
==SRF Replacement - Constraints Part==
Line 14: Line 15:
** It includes turning the clocks on, bringing the clockdomain out of inactive, power domain out of RET or OFF (with context restore) state.  
** 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.
** 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.
 +
 +
* '''Throughput latency constraint'''
 +
** This constraint can be used to set the minimum L3 rate in the system
===Details of Interrupt Latency===
===Details of Interrupt Latency===
Line 19: Line 23:
* The CPUidle menu governor also looks at CPU_DMA_LATENCY before deciding on the target C state
* 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.  
* 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.
+
* User needs to create a pm_qos handle and this handle is used to identify the device putting the constraint.
 +
* API Details:
 +
** int omap_pm_set_max_mpu_wakeup_lat(struct pm_qos_request_list **qos_request, long t);
 +
** @qos_request: handle for the constraint. The pointer should be initialized to NULL
 +
** @t: maximum MPU wakeup latency in microseconds
 +
 
 +
** void omap_pm_set_max_sdma_lat(struct pm_qos_request_list **qos_request, long t);
 +
** @qos_request: handle for the constraint. The pointer should be initialized to NULL
 +
** @t: maximum DMA transfer start latency in microseconds
 +
 
===Details of Device Latency===
===Details of Device Latency===
Line 28: Line 41:
* 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.
* 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.
* 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.
 +
* API Details
 +
** int omap_pm_set_max_dev_wakeup_lat(struct device *req_dev, struct device *dev, long t);
 +
** @req_dev: struct device * requesting the constraint, or NULL if none
 +
** @dev: struct device * to set the constraint one
 +
** @t: maximum device wakeup latency in microseconds
 +
 +
===Details of throughput constraint===
 +
* User can can set the required throughput by using throughput API omap_pm_set_min_bus_tput
 +
* User needs to calculate the throughput based on the usecases requirement.
 +
* throughput is mapped to l3 frequency using the formula l3_freq = (throughput in KB/sec * 1000/4)
 +
* API Details
 +
** void omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r);
 +
** @dev: struct device * requesting the constraint
 +
** @tbus_id: interconnect to operate on (OCP_{INITIATOR,TARGET}_AGENT)
 +
** @r: minimum throughput (in KiB/s)
===Proposed Implementation===
===Proposed Implementation===
Line 98: Line 126:
| align="center" | '''Comments & Actions'''
| align="center" | '''Comments & Actions'''
|-
|-
-
| Start with the design as aligned in the workshop and implement check for state change function || Vibhore || 25-Jun || Completed || 30-Jun: Completed 23-Jun: On track || None
+
| Start with the design as aligned in the workshop and implement check for state change function || Vibhore || 25-Jun || Completed || '''30-Jun: ''' Completed '''23-Jun: ''' On track || None
 +
|-
 +
| Resolve any compilation issues & test on zoom3 || Vibhore || '''New: ''' 07-Jul ''' Old: ''' 28-Jun  || Completed || '''07-Jul: ''' Faced few issues with test code which had to be developed for testing device latency constraints''' 02-Jul: ''' debugging & functionality testing '''23-Jun: ''' None || None
 +
|-
 +
| Internally post device latency constraints for review || Vibhore || '''New: ''' 19-Jul  '''Old: ''' 12-Jul || Completed || '''19-Jul: ''' Vishwa provided the review comments; '''14-Jul: ''' Delayed as Vibhore is on leave '''07-Jul: ''' None || None
 +
|-
 +
| Fix review comments, re-validate & post to LO || Vibhore || '''New: ''' 06-Aug  '''Old: ''' 28-Jul || Completed || '''11-Aug: ''' Posted to LO '''04-Aug: ''' Posted to PM domain mailing list & fixing review comments received; validation on OMAP4 is limited due to non-availablity of CORE RET & OFF in OMAP4 till now '''21-Jul: ''' Revalidation on OMAP3 will be done by 23-Jul and on OMAP4 by 28-Jul || None
 +
|-
 +
| Validate device latency constraints on OMAP4 & post to LO || Vibhore || 30-Sep || Not started || '''11-Aug: ''' Patches are there; they need to be validated on OMAP4 once CORE RET & CORE OFF is supported on OMAP4 || Depends on availability of CORE RET & CORE OFF functionality on OMAP4
 +
|-
 +
| Implement interrupt latency constraints using PM QoS || Vishwa || '''New: ''' 21-Jul '''Old: ''' 15-Jul || Completed || '''21-Jul: ''' Vishwa has completed the implementation '''14-Jul: ''' Delayed as Vibhore is on leave '''07-Jul: ''' None || None
|-
|-
-
| Resolve any compilation issues & test on blaze || Vibhore || 28-Jun || Completed|| 30-Jun: Completed 23-Jun: None || None
+
| Post RFC patches for interrupt latency || Vishwa || '''New: ''' 22-Jul, '''Old: ''' 19-Jul, 30-Jun || Completed || '''04-Aug: ''' Submitted to L24.9 '''21-Jul: ''' No major comments expected as the changes are straight forward '''07-Jul: ''' Prioritized the device latency constraint implementation which is new '''02-Jul: ''' Delayed, '''23-Jun: ''' None || None
|-
|-
-
| Post RFC patches || Vibhore || 30-Jun || Under Progress || 30-Jun: On track 23-Jun: None || None
+
| Implement throughput constraints & post RFC patches || Shweta || '''New: ''' 24-Aug '''Old: ''' 13-Aug, 06-Aug 30-Jul, 22-Jul || In progress || '''18-Aug: ''' Posted OMAP3 patches to LO; OMAP4 testing is ongoing - target 24-Aug for posting'''11-Aug: ''' Delayed due more time needed to address the internal review comments received '''04-Aug:''' Posted to internal mailing list; fixing the review comments received. Targeting 06-Aug for posting to LO. Anyway, this feature has a dependency on CORE DVFS '''21-Jul: ''' Basic implementation is done; OMAP3 validation targeted for 23-Jul; OMAP4 validation will start once CORE DVFS with min defconfig is functional on OMAP4 || '''07-Jul: ''' Requires DVFS functionality which is available on OMAP3 today and will be done for OMAP4 by the target date
|-
|-
-
| Extensive testing on OMAP3 & OMAP4 and rework to address review comments || Vibhore || 31-Jul || Not started || 23-Jun: None || None
+
| Extensive testing on OMAP3 & OMAP4 and rework to address review comments || Vibhore || '''New: ''' TBD '''Old: '''31-Jul || Not started || '''21-Jul: ''' Needs to be done during PM camp as drivers expressing constraints need to be in place; may happen by Sep end '''23-Jun: ''' None || None
|-
|-
|
|
|}
|}

Latest revision as of 10:22, 18 August 2010

Contents

[edit] Introduction

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

Here is an overview presentation: File:Latency constraint summary.ppt

[edit] SRF Replacement - Constraints Part

[edit] Types of Latency Constraints

[edit] Details of Interrupt Latency


[edit] Details of Device Latency

[edit] Details of throughput constraint

[edit] Proposed Implementation

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

[edit] Implementation Schedule

Post PM Workshop Deliverables for SRF Replacement - Constraints Part

Task Owner Target Date State Status Comments & Actions
Start with the design as aligned in the workshop and implement check for state change function Vibhore 25-Jun Completed 30-Jun: Completed 23-Jun: On track None
Resolve any compilation issues & test on zoom3 Vibhore New: 07-Jul Old: 28-Jun Completed 07-Jul: Faced few issues with test code which had to be developed for testing device latency constraints 02-Jul: debugging & functionality testing 23-Jun: None None
Internally post device latency constraints for review Vibhore New: 19-Jul Old: 12-Jul Completed 19-Jul: Vishwa provided the review comments; 14-Jul: Delayed as Vibhore is on leave 07-Jul: None None
Fix review comments, re-validate & post to LO Vibhore New: 06-Aug Old: 28-Jul Completed 11-Aug: Posted to LO 04-Aug: Posted to PM domain mailing list & fixing review comments received; validation on OMAP4 is limited due to non-availablity of CORE RET & OFF in OMAP4 till now 21-Jul: Revalidation on OMAP3 will be done by 23-Jul and on OMAP4 by 28-Jul None
Validate device latency constraints on OMAP4 & post to LO Vibhore 30-Sep Not started 11-Aug: Patches are there; they need to be validated on OMAP4 once CORE RET & CORE OFF is supported on OMAP4 Depends on availability of CORE RET & CORE OFF functionality on OMAP4
Implement interrupt latency constraints using PM QoS Vishwa New: 21-Jul Old: 15-Jul Completed 21-Jul: Vishwa has completed the implementation 14-Jul: Delayed as Vibhore is on leave 07-Jul: None None
Post RFC patches for interrupt latency Vishwa New: 22-Jul, Old: 19-Jul, 30-Jun Completed 04-Aug: Submitted to L24.9 21-Jul: No major comments expected as the changes are straight forward 07-Jul: Prioritized the device latency constraint implementation which is new 02-Jul: Delayed, 23-Jun: None None
Implement throughput constraints & post RFC patches Shweta New: 24-Aug Old: 13-Aug, 06-Aug 30-Jul, 22-Jul In progress 18-Aug: Posted OMAP3 patches to LO; OMAP4 testing is ongoing - target 24-Aug for posting11-Aug: Delayed due more time needed to address the internal review comments received 04-Aug: Posted to internal mailing list; fixing the review comments received. Targeting 06-Aug for posting to LO. Anyway, this feature has a dependency on CORE DVFS 21-Jul: Basic implementation is done; OMAP3 validation targeted for 23-Jul; OMAP4 validation will start once CORE DVFS with min defconfig is functional on OMAP4 07-Jul: Requires DVFS functionality which is available on OMAP3 today and will be done for OMAP4 by the target date
Extensive testing on OMAP3 & OMAP4 and rework to address review comments Vibhore New: TBD Old: 31-Jul Not started 21-Jul: Needs to be done during PM camp as drivers expressing constraints need to be in place; may happen by Sep end 23-Jun: None None
Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox