OMAP Power Management/SmartReflex
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).. it might be good to add them part of elinux.org/powermanagement/smartreflex todo page... but here it goes (typing these offline) - ok I think we are setting the stage for a phase 3 of evolution for voltage setting code on OMAPx series (Good :) ):
Intro to Smart reflex
Before I start, a bit of an intro for folks not exact 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
I) Implementation Consideration: (Manjunath G.K)
A) 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);
if (!irq_disabled()) cpu_relax() based delays of iteration count (1)?
II) Re-architecture Consideration: (Benoit Cusson):
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) 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 HWMOD infrastructure 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..
III) 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?