OPP Layer
From OMAPpedia
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
- Remove OPP control from SRF
- Store frequency table in the relevant hwmod (mpu, dsp, l3, ducati, hsi…)
- It will allow a better scalability than the current global structs
- Export a generic API in omap-pm or omap_device to set frequency of any scalable IP instead of the specifics cpu / dsp one.
- Handle Voltage OPP related information (Nvalue, gain, abb mode…) in a chip specific table that should be provided at init from pmXX.c. *SmartReflex driver will retrieve the correct information based on input voltage only. No need for opp_id.
- Configure ABB (SR2) settings based on the OPP and silicon strength (efuse information).
- No hard coded link between frequency table and voltage domain.
- The link is device dependant and can even be board dependant (one SMPS for several scalable domain)
- Need to handle the dependencies between voltage domain in a flexible manner and not hard coded. Must be able to handle cross OPP limitations that exist on OMAP4 (see note below).
- Regulator framework should be considered on top on smartreflex or at least on top of VP/VC.
- Need to handle clock throttling (frequency scaling at the same voltage)
- Dynamic OPP introduction and revocation
- Potentially modify CPUFreq for OPP removal
[edit] OPP Management Design
- There is a shift in the approach from voltage domain based OPP to device based OPP
- Device based OPP is needed for devices in VDD_CORE in OMAP4
- 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.
[edit] Implementation Phases
Here is the aligned distribution of work over different phases.
- Phase1
- Remove SRF code for VDD / frequency management
- Remove the usage of VDD id
- Replace it by a per voltage domain voting mechanism that allow several clients to request a voltage
- Add a new mechanism in order to link OPPs or voltage domains together
- Link the exisitng OPP tables with the corresponding hwmod structures
- Add a generic API at the omap device layer to do generic device opp scaling.
- Phase2
- Omap3 DVFS support
- Basic Omap4 DVFS support (for mpu and iva VDD)
- Phase3
- Populate OPP tables for IP with frequency limitation (MMC, USB, HSI...)
- Link the device opp tables with corresponding hwmod structures.
- Implement device specific set_rate which can be called to scale the internal dividers.
- Basic DVFS support for OMAP4 VDD Core.
- Phase4
- Add API's at the clock framework level to allow drivers to block and allow changes on the interested clocks.
- Extend the generic opp scaling API to take into account various ip's blocking and allowing the clock change.
- Introduce intelligent scaling of voltage where it is ok to bump up the voltage even if some ip's belonging to the voltage domain is running at a lower speed.
- Phase5
- Introduce regulator framework in order to handle voltage domains under SR control
[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:
- Ducati modules use Syslink interface to set the Clock rate constraints on A9 side
- If set rate needs to be implemented for ISS, it might need to be done on Ducati side via syslink. TO be confirmed
- Ducati Resource Manager calculates the IVAHD Load based on the usecase and requests the required frequency via syslink
- syslink will use Constraint/DVFS APIs for setting clock rate
Actions:
- ISS team to investigate further if there is any impact on ISS module or not with OMAP4 DVFS - Abhishek
- If ISS is impacted, then need to figure out how to implement this on A9 side or Ducati side – Kiran/Paul
- Schedule a call to align on Constraint Framework APIs for OMAP4 - Vishwa
