1. 21 12月, 2010 1 次提交
  2. 18 12月, 2010 2 次提交
  3. 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
  4. 01 12月, 2010 2 次提交
  5. 17 11月, 2010 1 次提交
  6. 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
  7. 06 10月, 2010 1 次提交
  8. 29 9月, 2010 2 次提交
  9. 28 9月, 2010 1 次提交
  10. 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
  11. 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
  12. 16 8月, 2010 1 次提交
  13. 02 8月, 2010 8 次提交
  14. 27 7月, 2010 2 次提交
  15. 05 7月, 2010 3 次提交
  16. 29 6月, 2010 1 次提交
  17. 21 5月, 2010 3 次提交
  18. 18 5月, 2010 1 次提交
  19. 14 5月, 2010 1 次提交
  20. 12 3月, 2010 1 次提交
  21. 25 2月, 2010 2 次提交
    • P
      OMAP hwmod: add hwmod class support · 43b40992
      Paul Walmsley 提交于
      Add support for categorizing and iterating over hardware IP blocks by
      the "class" of the IP block.  The class is the type of the IP block:
      e.g., "timer", "timer1ms", etc.  Move the OCP_SYSCONFIG/SYSSTATUS data
      from the struct omap_hwmod into the struct omap_hwmod_class, since
      it's expected to stay consistent for each class.  While here, fix some
      comments.
      
      The hwmod_class structures in this patch were designed and proposed by
      Benoît Cousson <b-cousson@ti.com> and were refined in a discussion
      between Thara Gopinath <thara@ti.com>, Kevin Hilman
      <khilman@deeprootsystems.com>, and myself.
      
      This patch uses WARN() lines that are longer than 80 characters, as
      Kevin noted a broader lkml consensus to increase greppability by
      keeping the messages all on one line.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NBenoît Cousson <b-cousson@ti.com>
      Cc: Thara Gopinath <thara@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      43b40992
    • P
      OMAP hwmod: convert header files with static allocations into C files · 7359154e
      Paul Walmsley 提交于
      Code should be able to #include any header file without the fear that
      the header file will go allocating memory.  This is a coding style
      issue, similar to commit 82e9bd58.
      Move the existing hwmod data from .h files to .c files.
      
      While here, convert "omap34xx" to "omap3xxx" in the hwmod files, since
      most of these structures should be reusable across all OMAP3 chips.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      7359154e