OPP Layer

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

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

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.



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

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 _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