OPP Layer

From OMAPpedia

Jump to: navigation, search

Contents

[edit] Introduction

This webpage describes the efforts of replacing the Shared Resource Framework (SRF) by OPP layer.

[edit] Requirements of SRF Replacement - OPP Part


[edit] OPP Management Design

OMAP OPP Mgmt Design.jpg


[edit] Implementation Phases

Here is the aligned distribution of work over different phases.


[edit] Implementation Schedule

[edit] VDD MPU & IVA DVFS on OMAP3

Task Owner Target Date State Status Comments & Actions
Do the data structural changes for introducing device OPP and get them working with existing SRF Kevin 16-Jun Completed 23-Jun: Kevin provided the patch series to Thara None
Get a branch with Kevin’s latest device-opp + voltage/sr layer without SRF Thara 23-Jun Completed 30-Jun: Completed on 24-Jun 23-Jun: Thara is woorking on them None
Replace reference to VDD numbers with VDD names Thara 25-Jun Completed 30-Jun: Completed the huge change None
Extend voltage layer to have a plist for each vdd to do the device use counting Thara New: 29-Jun Old: 25-Jun Completed 30-Jun: Completed 23-Jun: None None
Extend omap device layer for adding new APIs omap_device_set_min_rate(hwmod, rate) & omap_device_get_cur_rate(dev) Thara New: 01-Jul Old: 29-Jun Completed 07-Jul: RFC patches posted to LO on 02-Jul 30-Jun: Work under progress 23-Jun: None None
Modify cpufreq framework to make use of omap-device layer API’s Thara New: 01-Jul Old: 02-Jul Completed 07-Jul: RFC patches posted to LO on 02-Jul 30-Jun: None 23-Jun: None None
Pull OPP Layer + Voltage Layer + SRF Removal patches into a separate branch on TI's omap4 tree Thara New: 07-Jul Old: 02-Jul Completed 14-Jul: Thara has rebased the above patches on kernel.org and validated the functionality; so a separate branch is no longer needed 07-Jul: Involved more work as the dependency patches pertaining to the OPP layer had be taken from Kevin's PM tree + Monday OFF for TII 30-Jun: None 23-Jun: None 07-Jul: On track to complete this activity today
Basic validation on OMAP3 board Thara 06-Jul Completed 07-Jul Validated completely on OMAP3430 23-Jun: None None

[edit] VDD MPU & IVA DVFS on OMAP4

Task Owner Target Date State Status Comments & Actions
Update HWMOD of all the OMAP4 modules in MPU & IVA domains with OPP table Thara New: 09-Jul Old: 05-Jul Completed 07-Jul: Delayed due to dependent task slippage 30-Jun: None 07-Jul: Should be able to close fast once dependency is completed 30-Jun: Dependency on the task "Pull OPP Layer + Voltage Layer + SRF Removal patches into a separate branch on TI's omap4 tree"
Validate DVFS for MPU & IVA Domains Thara New: 21-Jul Old: 14-Jul, 09-Jul Completed 04-Jul: Done and demoed 21-Jul: Discovered discrepency between the rate at which IVA DPLL is locked and the rate reported by the clock framework; will complete the validation with temporary solution by 21-Jul; final solution will be tracked under a separate action item 14-Jul: MPU domain DVFS validation is complete; IVA domain DVFS implementation is in progress 07-Jul: None 30-Jun: None 07-Jul: Dependency on "Update HWMOD of all the OMAP4 modules in MPU & IVA domains with OPP table "

[edit] VDD CORE DVFS on OMAP3 & OMAP4

Task Owner Target Date State Status Comments & Actions
Implement set_rate for all the platform & power modules with scalable clocks on OMAP4 Vishwa New: 13-Aug Old: 09-Aug, 20-Jul, 09-Jul In Progress 11-Aug: Only McBSP4 supports scalable clocks and today there are no users of McBSP4; so set_rate implementation is currently not needed for McBSP. Thara will integrate MMC set_rate changes in her CORE DVFS patch and test it. 04-Aug: At platform and power level, MMC & MCBSP require set_rate implementation. MMC changes are ready; waiting on slow card availability for validation. McBSP waiting on HWMOD adaptation by 09-Aug14-Jul: Risk Not much progress made by module owners; high chances of slipping and thereby risking CORE DVFS schedule 07-Jul: One round of discussions with all the impacted modules completed; awaiting their schedule for implementation 30-Jun: Discussions started 07-Jul: Implementation for "all" modules is needed for extensive validation milestone only. Validation of DVFS for core domain can still go ahead with limited set of drivers.
Extend voltage layer to introduce cross VDD dependencies Vishwa New: 16-Jul Old: 09-Jul Completed 14-Jul: Implementation complete; validated on OMAP3; validation on OMAP4 in progress 07-Jul: Dates need to be replanned based on progress of MPU & IVA validation on OMAP4 30-Jun: None None
Update HWMOD with OPP table for core domain modules Thara New: TBD Jul Old: 16-Jul, 14-Jul Completed 21-Jul: Validated for OMAP3; partial changes done for OMAP4; will be done along with set_rate implementation 14-Jul: Thara can take this up after finishing IVA validation 07-Jul: Dates need to be replanned based on progress of MPU & IVA validation on OMAP4 30-Jun: None None
Validate DVFS for core domain with min defconfig Thara & Vishwa 27-Jul Completed 21-Jul: Analysis done; no dependency on set_rate implementation; will start once IVA DVFS valdation is over None
Validate DVFS for core domain with all platform and power drivers Thara & Vishwa New: 18-Aug Old: 13-Aug, 30-Jul, 23-Jul, 19-Jul In Progress 11-Aug: Thara has validated without MMC set_rate implementation. Validation with MMC set_rate included is in progress. Will be posted to LO by 13-Aug for review. 04-Aug: Depends on McBSP set_rate implementation availability by 09-Aug 21-Jul: Completion depends on availability of set-Rate for MMC & McBSP by 27-Jul 14-Jul: Dates need to be replanned based on progress of set_rate implementation for all the modules with scalable clocks on OMAP4 07-Jul: Dates need to be replanned based on progress of MPU & IVA validation on OMAP4 30-Jun: None None
Extensive Validation of DVFS on OMAP3/OMAP4 Thara & Vishwa New: 30-Aug Old: 30-Jul Not started 04-Aug: Needs to be done at system level; will be done as part of the camp 21-Jul: Risk of 2 weeks; but still can meet the Aug mid milestone 14-Jul: Risk of 2 weeks ; Need to prioritize set_rate implementation 07-Jul: None 30-Jun: None 07-Jul: By Thara working on CORE DVFS and Vishwa working on MPU & IVA DVFS, we should be able to meet this target

[edit] Implementation of Custom Set Rates

As part of DVFS implementation for OMAP4, there are some modules in OMAP4 that have scalable clocks which need to be scaled along with DVFS. These clocks are controlled inside the module and not via PRCM. So to control these clocks in DVFS, proposal is to implement set_rate function inside the module driver and expose this function via modules's hwmod databse. DVFS will call this set_rate as part of DVFS. This set_rate will scale all the scalable clocks inside the module.

API Signature: int <ModuleName>_set_rate((struct clk *clk, unsigned long rate);

clk : main scalable clock of the module

rate: target rate of main scalable clock


Impacted modules and owners are:

MMC – Sukumar

MCBSP4 – Nishant

HSI – Nishant

MS Pro - Nishant

UNIPro – Nishant

ISS – Kiran

DSS – Sendhil

Target Date: July 7

Minutes of the alignment call (07/01/2010)

Attendees: Vishwa, Partha, Paul, Santosh, Kiran, Abhishek, Vikram, Mike, Shweta

Minutes:

Actions:

[edit] Patches In Progress

File:SRF Replacement OPP Part RFC Patch.pdf

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox