1. 23 12月, 2010 5 次提交
    • T
      OMAP3: PM: Register TWL4030 pmic info with the voltage driver. · fbc319f6
      Thara Gopinath 提交于
      This patch registers the TWL4030 PMIC specific informtion
      with the voltage driver. Failing this patch the voltage driver
      is unware of the formula to use for vsel to voltage and vice versa
      conversion and lot of other PMIC dependent parameters.
      
      This file is based on the arch/arm/plat-omap opp_twl_tpl.c file
      by Paul Walmsley. The original file is replaced by this file.
      Signed-off-by: NThara Gopinath <thara@ti.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      fbc319f6
    • T
      OMAP3: PM: Adding smartreflex class3 driver · fa765823
      Thara Gopinath 提交于
      Smartreflex Class3 implementation continuously monitors
      silicon performance  and instructs the Voltage Processors
      to increase or decrease the voltage.
      This patch adds smartreflex class 3 driver. This driver hooks
      up with the generic smartreflex driver smartreflex.c to abstract
      out class specific implementations out of the generic driver.
      
      Class3 driver is chosen as the default class driver for smartreflex.
      If any other class driver needs to be implemented, the init of that
      driver should be called from the board file. That way the new class driver
      will over-ride the Class3 driver.
      Signed-off-by: NThara Gopinath <thara@ti.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      fa765823
    • T
      OMAP3: PM: Adding smartreflex device file. · 0c0a5d61
      Thara Gopinath 提交于
      This patch adds support for device registration of various
      smartreflex module present in the system. This patch introduces
      the platform data for smartreflex devices which include
      the efused n-target vaules, a parameter to indicate
      whether smartreflex autocompensation needs to be
      enabled on init or not. An API
      omap_enable_smartreflex_on_init is provided for the
      board files to enable smartreflex autocompensation during
      system boot up.
      Signed-off-by: NThara Gopinath <thara@ti.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      0c0a5d61
    • T
      OMAP3: PM: Adding smartreflex driver support. · 984aa6db
      Thara Gopinath 提交于
      SmartReflex modules do adaptive voltage control for real-time
      voltage adjustments. With Smartreflex the power supply voltage
      can be adapted to the silicon performance(manufacturing process,
      temperature induced performance, age induced performance etc).
      
      There are differnet classes of smartreflex implementation.
      	Class-0: Manufacturing Test Calibration
      	Class-1: Boot-Time Software Calibration
      	Class-2: Continuous Software Calibration
      	Class-3: Continuous Hardware Calibration
      	Class-4: Fully Integrated Power Management
      
      OMAP3 has two smartreflex modules one associated with VDD MPU and the
      other associated with VDD CORE.
      This patch adds support for  smartreflex driver. The driver is designed
      for Class-1 , Class-2 and Class-3 support and is  a platform driver.
      Smartreflex driver can be enabled through a Kconfig option
      "SmartReflex support" under "System type"->"TI OMAP implementations" menu.
      
      Smartreflex autocompensation feature can be enabled runtime through
      a debug fs option.
      To enable smartreflex autocompensation feature
      	echo 1 > /debug/voltage/vdd_<X>/smartreflex/autocomp
      To disable smartreflex autocompensation feature
      	echo 0 > /debug/voltage/vdd_<X>/smartreflex/autocomp
      
      where X can be mpu, core , iva etc.
      
      This patch contains code originally in linux omap pm branch.
      Major contributors to this driver are
      Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
      Nishant Menon, Kevin Hilman.
      Signed-off-by: NThara Gopinath <thara@ti.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      984aa6db
    • T
      OMAP3: PM: Adding voltage driver support. · 2f34ce81
      Thara Gopinath 提交于
      This patch adds voltage driver support for OMAP3. The driver
      allows  configuring the voltage controller and voltage
      processors during init and exports APIs to enable/disable
      voltage processors, scale voltage and reset voltage.
      The driver maintains the global voltage table on a per
      VDD basis which contains the various voltages supported by the
      VDD along with per voltage dependent data like smartreflex
      efuse offset, errminlimit and voltage processor errorgain.
      The driver also allows the voltage parameters dependent on the
      PMIC to be passed from the PMIC file through an API.
      The driver allows scaling of VDD voltages either through
      "vc bypass method" or through "vp forceupdate method" the
      choice being configurable through the board file.
      
      This patch contains code originally in linux omap pm branch
      smartreflex driver.  Major contributors to this driver are
      Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
      Nishant Menon, Kevin Hilman. The separation of PMIC parameters
      into a separate structure which can be populated from
      the PMIC file is based on the work of Lun Chang from Motorola
      in an internal tree.
      Signed-off-by: NThara Gopinath <thara@ti.com>
      [khilman: fixed link error for OMAP2-only defconfig]
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      2f34ce81
  2. 22 12月, 2010 10 次提交
  3. 21 12月, 2010 1 次提交
  4. 18 12月, 2010 3 次提交
  5. 08 12月, 2010 1 次提交
    • V
      OMAP: GPIO: Implement GPIO as a platform device · 77640aab
      Varadarajan, Charulatha 提交于
      Implement GPIO as a platform device.
      
      GPIO APIs are used in machine_init functions. Hence it is
      required to complete GPIO probe before board_init. Therefore
      GPIO device register and driver register are implemented as
      postcore_initcalls.
      
      omap_gpio_init() does nothing now and this function would be
      removed in the next patch as it's usage is spread across most
      of the board files.
      
      Inorder to convert GPIO as platform device, modifications are
      required in clockxxxx_data.c file for OMAP1 so that device names
      can be used to obtain clock instead of getting clocks by
      name/NULL ptr.
      
      Use runtime pm APIs (pm_runtime_put*/pm_runtime_get*) for enabling
      or disabling the clocks, modify sysconfig settings and remove usage
      of clock FW APIs.
      Note 1: Converting GPIO driver to use runtime PM APIs is not done as a
      separate patch because GPIO clock names are different for various OMAPs
      and are different for some of the banks in the same CPU. This would need
      usage of cpu_is checks and bank id checks while using clock FW APIs in
      the gpio driver. Hence while making GPIO a platform driver framework,
      PM runtime APIs are used directly.
      
      Note 2: While implementing GPIO as a platform device, pm runtime APIs
      are used as mentioned above and modification is not done in gpio's
      prepare for idle/ resume after idle functions. This would be done
      in the next patch series and GPIO driver would be made to use dev_pm_ops
      instead of sysdev_class in that series only.
      
      Due to the above, the GPIO driver implicitly relies on
      CM_AUTOIDLE = 1 on its iclk for power management to work, since the
      driver never disables its iclk.
      This would be taken care in the next patch series (see Note 3 below).
      
      Refer to
      http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39112.html
      for more details.
      
      Note 3: only pm_runtime_get_sync is called in gpio's probe() and
      pm_runtime_put* is never called. This is to make the implementation
      similar to the existing GPIO code. Another patch series would be sent
      to correct this.
      
      In OMAP3 and OMAP4 gpio's debounce clocks are optional clocks. They
      are enabled/ disabled whenever required using clock framework APIs
      
      TODO:
      1. Cleanup the GPIO driver. Use function pointers and register
      offest pointers instead of using hardcoded values
      2. Remove all cpu_is_ checks and OMAP specific macros
      3. Remove usage of gpio_bank array so that only
         instance specific information is used in driver code
      4. Rename 'method'/ avoid it's usage
      5. Fix the non-wakeup gpios handling for OMAP2430, OMAP3 & OMAP4
      6. Modify gpio's prepare for idle/ resume after idle functions
         to use runtime pm implentation.
      Signed-off-by: NCharulatha V <charu@ti.com>
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Reviewed-by: NBasak, Partha <p-basak2@ti.com>
      Acked-by: NKevin Hilman <khilman@deeprootsystems.com>
      [tony@atomide.com: updated for bank specific revision and updated boards]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      77640aab
  6. 01 12月, 2010 2 次提交
  7. 17 11月, 2010 1 次提交
  8. 09 10月, 2010 2 次提交
    • P
      OMAP: split plat-omap/common.c · aa218daf
      Paul Walmsley 提交于
      Split plat-omap/common.c into three pieces:
      
      1. the 32KiHz sync timer and clocksource code, which now lives in
         plat-omap/counter_32k.c;
      
      2. the OMAP2+ common code, which has been moved to mach-omap2/common.c;
      
      3. and the remainder of the OMAP-wide common code, which includes the
         deprecated ATAGs code and a deprecated video RAM reservation function.
      
      The primary motivation for doing this is to move the OMAP2+-specific parts
      into an OMAP2+-specific file, so that build breakage related to the
      System Control Module code can be resolved.
      
      Benoît Cousson <b-cousson@ti.com> suggested a new filename and found
      some bugs in the counter_32k.c comments - thanks Benoît.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      aa218daf
    • E
      omap3: Add minimal OMAP3 IGEP module support · e844b1da
      Enric Balletbo i Serra 提交于
      The OMAP3 IGEP module is a low-power, high performance production-ready
      system-on-module (SOM) based on TI's OMAP3 family. More about this
      board at www.igep.es.
      Signed-off-by: NEnric Balletbo i Serra <eballetbo@gmail.com>
      [tony@atomide.com: updated for the mmc changes and to be selected by default]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      e844b1da
  9. 06 10月, 2010 1 次提交
  10. 29 9月, 2010 2 次提交
  11. 28 9月, 2010 1 次提交
  12. 24 9月, 2010 1 次提交
    • B
      OMAP4: hwmod: Add initial data for OMAP4430 ES1 & ES2 · 55d2cb08
      Benoit Cousson 提交于
      The current version contains only the interconnects and the
      mpu hwmods.
      The remaining hwmods will be introduced by further patches on
      top of this one.
      
      - enable as well omap_hwmod.c build for OMAP4 Soc
      
      Please not that this file uses the new naming convention for
      naming HW IPs. This convention will be backported soon for previous
      OMAP2 & 3 data files.
      
      new name        trm name
      -------------   -------------------
      counter_32k     synctimer_32k
      l3_main         l3
      timerX          gptimerX / dmtimerX
      mmcX            mmchsX / sdmmcX
      dma_system      sdma
      smartreflex_X   sr_X / sr?
      usb_host_fs     usbfshost
      usb_otg_hs      hsusbotg
      usb_tll_hs      usbtllhs_config
      wd_timerX       wdtimerX
      ipu             cortexm3 / ducati
      dsp             c6x / tesla
      iva             ivahd / iva2.2
      kbd             kbdocp / keyboard
      mailbox         system_mailbox
      mpu             cortexa9 / chiron
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      55d2cb08
  13. 22 9月, 2010 3 次提交
    • P
      OMAP2/3: PRM: add module hard reset support · cf21405f
      Paul Walmsley 提交于
      This patch adds hard-reset support for processor modules (e.g., DSP, IVA)
      on OMAP2/3 platforms.  It's based on the OMAP4 hard-reset support that Benoît
      developed in the previous patch.
      
      This patch is a collaboration between Benoît Cousson <b-cousson@ti.com>
      and Paul Walmsley <paul@pwsan.com>.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      cf21405f
    • B
      OMAP4: PRM: add module hard reset support · 0be1621a
      Benoît Cousson 提交于
      Most processor modules (e.g., DSP, IVA, IPU) on OMAPs can be reset
      under the control of the PRM.  This patch adds an API for this purpose
      for OMAP4 devices:
      
      int omap4_prm_is_hardreset_asserted(void __iomem *rstctrl_reg, u8 shift);
      int omap4_prm_assert_hardreset(void __iomem *rstctrl_reg, u8 shift);
      int omap4_prm_deassert_hardreset(void __iomem *rstctrl_reg, u8 shift);
      
      This API is intended to be used only by the hwmod code - a subsequent
      patch will add that support to hwmod.
      
      This patch is a collaboration between Benoît Cousson <b-cousson@ti.com>
      and Paul Walmsley <paul@pwsan.com>.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NBenoît Cousson <b-cousson@ti.com>
      Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
      0be1621a
    • K
      OMAP2+: PM: initial runtime PM core support · 57e6fe7b
      Kevin Hilman 提交于
      Implement the new runtime PM framework as a thin layer on top of the
      omap_device API.  OMAP specific runtime PM methods are registered with
      the as custom methods on the platform_bus.
      
      In order to determine if a device is an omap_device, its parent device
      is checked.  All omap_devices have a new 'omap_device_parent_ device
      as their parent device, so checking for this parent is used to check
      for valid omap_devices.  If a device is an omap_device, then the
      appropriate omap_device functions are called for it.  If not, only the
      generic runtime PM functions are called.
      
      Device driver's ->runtime_idle() hook is called when the runtime PM
      usecount reaches zero for that device.  Driver's ->runtime_suspend()
      hooks are called just before the device is disabled (via
      omap_device_idle()), and device driver ->runtime_resume() hooks are
      called just after device has been enabled (via omap_device_enable().)
      
      OMAP4 build support from Rajendra Nayak <rnayak@ti.com>.
      OMAP2 build support from Charulatha V <charu@ti.com>
      
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Charulatha V <charu@ti.com>
      Acked-by: NGrant Likely <grant.likely@secretlab.ca>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      57e6fe7b
  14. 16 8月, 2010 1 次提交
  15. 02 8月, 2010 6 次提交