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)..I think we are setting the stage for a phase 3 of evolution for voltage setting code on OMAPx series (Good :) ): Ref:

• initial rev 2 RFC series - called rev2 considering the original SR was rev 1
• Rev 3
• Rev 4

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

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

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:

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

Smartreflex revamp

Requirements

1. Support all functional fixes done so far (enable / disable sequence, timeout adjustment…)
2. 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
3. Support SmartReflex IP v1 (3430) and v2 (3630 and 4430)
4. Add the capability to support various Power ICs
   • with SR I2C in class3 (T2/GAIA/Phoenix)
   • with regular I2C in class2 mode
5. Support smartreflex omap_hwmod
6. Separate the Power IC SR I2C initialization from the initialization of the VP/VC in respectively Power IC driver and SoC specific code
7. Separate the efuse extraction from the smartreflex code as the efuse location and value are chip specific information
8. Support Nvalue through debugfs for debug purpose or Nvalue refinement
9. Support SW Nvalue for early silicon without efuse
10. Provide a voltage <-> OPP mapping table in order to get the correct Nvalue without any dependency to the OPP layer / OPP table
11. 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.
12. Support Smartreflex for retention voltage
13. Use the voltage regulator framework to handle DCDCs controlled by SmartReflex
14. Optimize the Smartreflex sequence based on idle state in order to avoid unnecessary transition.

Proposal

Patch1

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

Patch2

• 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

Patch3

• Implement the latest recommended sequences for SR and VP disable and recommended register settings or VP and SR.

Patch4

• VPforce update method of voltage scaling

Patch5

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

Patch6

• 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?