1. 16 9月, 2011 6 次提交
    • K
      OMAP3+: VC: cleanup PMIC register address configuration · e4e021c5
      Kevin Hilman 提交于
      - support both voltage register address and command register address
        for each VC channel
      - add fields for voltage register address (volra) and command register
        address (cmdra) to struct omap_vc_channel
      - use VC/VP register access read/modify/write helper
      - remove volra_shift field (use __ffs(mask) for shift value)
      - I2C addresses 10-bit, change size to u16
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      e4e021c5
    • K
      OMAP3+: VC: cleanup i2c slave address configuration · ba112a4e
      Kevin Hilman 提交于
      - Add an i2c_slave_address field to the omap_vc_channel
      - use VC/VP read/modify/write helper instead of open-coding
      - remove smps_sa_shift, use __ffs(mask) for shift value
      - I2C addresses 10-bit, change size to u16
      
      Special thanks to Shweta Gulati <shweta.gulati@ti.com> for suggesting
      the use of __ffs(x) instead of ffs(x) - 1.
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      ba112a4e
    • K
      OMAP3+: voltage: convert to PRM register access functions · 4bcc475e
      Kevin Hilman 提交于
      Convert VC/VP register access to use PRM VC/VP accessor functions.  In
      the process, move the read/write function pointers from vdd_info into
      struct voltagedomain.
      
      No functional changes.
      
      Additional cleanup:
      - remove prm_mod field from  VC/VP data structures, the PRM register
        access functions know which PRM module to use.
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      4bcc475e
    • K
      OMAP2+: voltage: move VC into struct voltagedomain, misc. renames · d84adcf4
      Kevin Hilman 提交于
      Move the VC instance struct from omap_vdd_info into struct voltagedomain.
      While moving, perform some misc. renames for readability.
      
      No functional changes.
      
      Summary of renames:
      - rename omap_vc_instance to omap_vc_channel, since there is only
        one instance of the VC IP and this actually represents channels
        using TRM terminology.
      - rename 'vc_common' field of VC channel which led to:
        s/vc->vc_common/vc->common/
      - remove redundant '_data' suffix
      - OMAP3: vc1 --> vc_mpu, vc2 --> vc_core
      - omap_vc_bypass_scale_voltage() -> omap_vc_bypass_scale()
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      
      merge
      d84adcf4
    • K
      OMAP2+: voltage: split voltage controller (VC) code into dedicated layer · ccd5ca77
      Kevin Hilman 提交于
      As part of the voltage layer cleanup, split out VC specific code into
      a dedicated VC layer.  This patch primarily just moves VC code from
      voltage.c into vc.c, and adds prototypes to vc.h.
      
      No functional changes.
      
      For readability, each function was given a local 'vc' pointer:
      
          struct omap_vc_instance_data *vc = voltdm->vdd->vc_data;
      
      and a global replace of s/vdd->vc_data/vc/ was done.
      
      Also vc_init was renamed to vc_init_channel to reflect that this is
      per-VC channel initializtion.
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      ccd5ca77
    • K
      OMAP2+: voltage: move PRCM mod offets into VC/VP structures · a7460daf
      Kevin Hilman 提交于
      Eliminate need for global variables for the various PRM module offsets by
      making them part of the VP/VC common structures
      
      Eventually, these will likely be moved again, or more likely removed
      when VP/VC code is isolated, but for now just getting rid of them as
      global variabes so that the voltage domain initialization can be
      cleaned up.
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      a7460daf
  2. 11 3月, 2011 1 次提交
    • P
      OMAP2+: voltage: reorganize, split code from data · c0718df4
      Paul Walmsley 提交于
      This is a first pass at reorganizing mach-omap2/voltage.c:
      
      - Separate almost all of the data from the code of mach-omap2/voltage.c.
        The code remains in mach-omap2/voltage.c.  The data goes into one
        of several places, depending on what type of data it is:
      
        - Silicon process/validation data: mach-omap2/opp*_data.c
        - VC (Voltage Controller) data: mach-omap2/vc*_data.c
        - VP (Voltage Processor) data: mach-omap2/vp*_data.c
        - Voltage domain data: mach-omap2/voltagedomains*_data.c
      
        The ultimate goal is for all this data to be autogenerated, the same
        way we autogenerate the rest of our data.
      
      - Separate VC and VP common data from VDD-specific VC and VP data.
      
      - Separate common voltage.c code from SoC-specific code; reuse common code.
      
      - Reorganize structures to avoid unnecessary memory loss due to unpacked
        fields.
      
      There is much left to be done.  VC code and VP code should be separated out
      into vc*.c and vp*.c files.  Many fields in the existing structures are
      superfluous, and should be removed.  Some code in voltage.c seems to be
      duplicated; that code should be moved into functions of its own.  Proper
      voltage domain code should be created, as was done with the powerdomain
      and clockdomains, and powerdomains should reference voltagedomains.
      
      Thanks to Shweta Gulati <shweta.gulati@ti.com> for comments.  Thanks
      to Rajendra Nayak <rnayak@ti.com> for finding and fixing some bugs
      that prevented OMAP4 from booting:
      
         https://patchwork.kernel.org/patch/587311/
      
      His patch has been folded into this one to avoid breaking OMAP4
      between patches.  Thanks also to Kevin Hilman <khilman@ti.com> for
      finding and fixing a compile problem when !CONFIG_PM:
      
         http://www.spinics.net/lists/arm-kernel/msg118067.html
      
      His patch has also been folded into this one to avoid breaking
      !CONFIG_PM builds.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Shweta Gulati <shweta.gulati@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      c0718df4