Difference between revisions of "OMAP Power Management/SmartReflex"

From eLinux.org
Jump to: navigation, search
Line 5: Line 5:
  
 
= Intro to Smart reflex =
 
= Intro to Smart reflex =
 +
Read [http://www.powersystemsdesign.com/index.php?option=com_content&view=article&id=168&Itemid=107 this] for an indepth description
 +
 
Before I start, a bit of an intro for folks not exactly dreaming Smart reflex voltage transitions every night:
 
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:
 
Smart reflex has various class of operations, to balance NDAism restrictions (:( ) and relevant info for this discussion:

Revision as of 14:42, 8 January 2010

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

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

I) Implementation Consideration:(v0.4)

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

Recomendation:

       cpu_relax() + udelay(1) loops

B) Kalle J: remove dead code synopsys

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:

   vc_send_command
   sr_vc_bypass

SR generic functions

   sr_write_reg
   sr_modify_reg
   sr_read_reg
   sr_vplimito_value
   sr_clk_enable
   sr_clk_disable

VP Functions:

   sr_vp_clear_vptransdone
   sr_vp_forceupdate
   sr_vp_enable
   sr_vp_disable
   sr_vp_configure
   sr_vp_reset_voltage

SR only functions:

   sr_enable
   sr_disable

Dual operation (sequencing related functions):

   srvp_disable
   srvp_enable

DVFS functions:

   sr_vp_enable_both
   sr_vp_disable_both
   sr_voltage_set

Cpuidle paths:

   disable_smartreflex
   enable_smartreflex

Sysfs entries:

   omap_sr_vdd_autocomp_show
   omap_sr_vdd_autocomp_store

init functions:

   srvp_init
   omap_sr_init

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

solution:

   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

Solution:

   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.

Solution:

   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?