OMAP Power Management/SmartReflex

< OMAP Power Management
Revision as of 09:59, 27 October 2009 by Nmenon (talk | contribs) (III) Further comments avenues of thought:)
Jump to: navigation, search

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 :) ):

Intro to Smart reflex

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

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())
   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:


DebugFS accessor functions:


PMIC functions -> over ride with weak functions.


Voltage controller functions:


SR generic functions


VP Functions:


SR only functions:


Dual operation (sequencing related functions):


DVFS functions:


Cpuidle paths:


Sysfs entries:


init functions:


Recommended naming:

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

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?