OMAP Power Management/SmartReflex
- 1 Quick updates from Smart Reflex pages
- 2 Intro to Smart reflex
- 3 Considerations on implementation directions
Quick updates from Smart Reflex pages
Thanks a bunch for various indepth reviews and comments incoming(keep them coming), I just looked these up in detail and attempted to summarize the discussion so far (please feel free to add/correct my notes)..I think we are setting the stage for a phase 3 of evolution for voltage setting code on OMAPx series (Good :) ): Ref:
Intro to Smart reflex
Read this for an indepth description
Before I start, a bit of an intro for folks not exactly dreaming Smart reflex voltage transitions every night: Smart reflex has various class of operations, to balance NDAism restrictions (:( ) and relevant info for this discussion:
- Class 2: SR acts like a notification mechanism to MPU - says, buddy u should change voltage to xyz, and MPU goes ahead and does the required stuff..
- Class 3: mostly automated: you hook up SR->VP->VC->PMIC and say go... and then control at critical points (changing OPP etc..) rest the h/w knobs when and how the voltage transitions.. MPU does not need to be involved when the transitions take place..
Now, SmartReflex(TM TI) has a h/w block for low MPU latency automated voltage control -> so you dont have to create 100 odd additional OPPs for same frequency and drive DVFS nuts doing transitions, instead let the h/w do it for you.. and with the right PMIC, it actually works too ;).. class 3 is the rocking ideal scenario, but you can do still better than a dumb set voltage x for OPP y with a class 2 operation.. all of these need chip specific NVALUES which are like chip specific calibration values put in.. not all silicon have this.(you still can experience the fun looking at my commit message for common omap3 usage tricks e.g. for 3530).. but note: once you start class3, h/w is gonna push the voltage to as low as possible.. things that were working "wrongly" at higher than optimal lower voltage will start breaking all around you.. so, be prepared(a.k.a plan for more time) to fix a bunch of stuff if you have not enabled SR before.. but, once you start using SR, go thru the pains and look at how this beauty works, there is no stepping back to inferior no-SR world anymore ;) (a.k.a addiction warning)..
Considerations on implementation directions
A) Manjunath G.K + Paul Walmsey: udelay() replace with better logic involving cpu_relax/udelay usage usage:
569 udelay(10); 617 udelay(omap_pmic_voltage_ramp_delay(sr->srid, 743 udelay(1); 806 udelay(1); 830 udelay(omap_pmic_voltage_ramp_delay(sr->srid, target_vsel, 912 udelay(1); 1045 udelay(1);
cpu_relax() + udelay(1) loops
B) Kalle J: remove dead code synopsys
Re-architecture Consideration: (Benoit Cousson):
A) Split function names to make it a little more re-organized:
Current set: OPP Accessor functions:
get_sr get_sr_from_vdd get_sr_from_vdd_name get_current_opp_number_from_sr get_vsel_for_opp
DebugFS accessor functions:
sr_debugfs_set sr_debugfs_get sr_debugfs_vselget sr_debugfs_create_entries sr_debugfs_create_entries_late
PMIC functions -> over ride with weak functions.
omap_pmic_srinit omap_pmic_voltage_ramp_delay omap_pmic_voltage_cmds
Voltage controller functions:
SR generic functions
sr_write_reg sr_modify_reg sr_read_reg sr_vplimito_value sr_clk_enable sr_clk_disable
sr_vp_clear_vptransdone sr_vp_forceupdate sr_vp_enable sr_vp_disable sr_vp_configure sr_vp_reset_voltage
SR only functions:
Dual operation (sequencing related functions):
sr_vp_enable_both sr_vp_disable_both sr_voltage_set
help me here guys..
B) PMIC weak function - causes issues with multiple platform builds with a mixture of PMIC enabled and PMIC disabled ones
Move the functions omap_pmic_xxx functions into board registration functions - but do it as a follow on patch based on need - how many folks are really interested in this?
C) Support of Class 2 systems: these are on Silicons where the PMIC support is "not smart" ;) essentially PMIC chip does not understand the OMAP smart reflex protocol and hence has to depend on the cpu intensive communication to be done.. Class 3 mode of smart reflex operation will not work here.. class 2 operations need: a) voltage setting using i2c1/spi or other interface layer - depending on PMIC involved b) two conditions here:
case i) Voltage setting cannot use forceupdate/vcbypass operations - these are ones which cannot use I2C4 to comunicate with PMIC.. case ii) vcbypass is usable, but Voltage processor based voltage setting is not usable..
c) SR essentially acts as a monitoring system.. it says -> oh CPU, we can infact change the amount of voltage used, some sort of monitoring mechanism such as hwmon is required
introduce class 2 operation later on..
D) Split functionality into various other files:
Current implementation has the naming based definition as above.. mebbe not enough.. but I am not partial to the same.. currently the functions are static and maintained as seperate entities but in general the assumption is Class 3 mode of SR operation.
introduce class 2 operation later on..
- Support all functional fixes done so far (enable / disable sequence, timeout adjustment…)
- Separate smartreflex code from voltage processor and voltage controller code
- smartreflex is an autonomous IP and should be implemented as an omap_device with a regular platform_driver
- VP+VC are part or the PRM and can be used without SR for device voltage management
- Support SmartReflex IP v1 (3430) and v2 (3630 and 4430)
- Add the capability to support various Power ICs
- with SR I2C in class3 (T2/GAIA/Phoenix)
- with regular I2C in class2 mode
- Support smartreflex omap_hwmod
- Separate the Power IC SR I2C initialization from the initialization of the VP/VC in respectively Power IC driver and SoC specific code
- Separate the efuse extraction from the smartreflex code as the efuse location and value are chip specific information
- Support Nvalue through debugfs for debug purpose or Nvalue refinement
- Support SW Nvalue for early silicon without efuse
- Provide a voltage <-> OPP mapping table in order to get the correct Nvalue without any dependency to the OPP layer / OPP table
- Use force update in VP as the default method, but still expose a VCbypass API to allow specific power IC to be configured using that API.
- Support Smartreflex for retention voltage
- Use the voltage regulator framework to handle DCDCs controlled by SmartReflex
- Optimize the Smartreflex sequence based on idle state in order to avoid unnecessary transition.
- Make Smartreflex.c a platform driver with SR1 and SR2 as omap_devices registering from board files.
- Add omap_hwmod for both SR instances in order to handle the chip specific information (base address / IRQ)
- Pass the N target values as pdata from the board file.
- Separate out vp and vc functions into a separate file voltagefunctions.c.
- Today in sr_init , we enable smartreflex on T2 side. Take it out and find an appropriate file for it.
- Make a file smartreflexclass3.c with the following functions which will be called from idle loop and dvfs to enable/disable SR.
- Define function pointers sr_class_enable and sr_class_disable in smartreflex.c and provide mechanism for class3 functions to hoop up to it. Thus enable_smartreflex in smartreflex.c file would just call sr_class_enable, which would in turn call sr_enable in smartreflex.c and vp_enable in voltagefunctions.c
- Implement the latest recommended sequences for SR and VP disable and recommended register settings or VP and SR.
- VPforce update method of voltage scaling
- Implement 3630 specific SR changes. This will involve slight changes in the design of Smartreflex module and will accommodate ways of plugging in various versions of SR IP. Here I propose to have a structure implemented with register offsets for various SR registers and values which can be populated runtime on chip id basis.
- Separate PMIC specific code from voltage and SR drivers
Further comments avenues of thought:
A) implementation: Stop using prm_reg_mod and functions of that effect -> they tie me down to OMAP3 or family.. but this has a system wide impact
B) re-architect: Dont need to enable/disable Smart reflex for every thing in life.. make the voltage scale decisions based on heuristics -> we hit OFF mode much often, then dont use smart reflex, it aint worth the latency.. this should be considered more as follows: as long as I stay in active mode for usecases for a longer term, enabling sr makes sense.. else, shut it off.. OFF mode is desirable compared to latencies involved..
C) have been maintaining the sr sysfs entries to maintain legacy code.. ow do folks feel about it being kicked back into debugfs?
D) clk speed should not be a dependency of SR code.. (ideal world ofcourse)..
E) sr_read/write_reg could be improved perhaps?