1. 10 7月, 2011 1 次提交
    • P
      omap_hwmod: use a null structure record to terminate omap_hwmod_addr_space arrays · 78183f3f
      Paul Walmsley 提交于
      Previously, struct omap_hwmod_addr_space arrays were unterminated; and
      users of these arrays used the ARRAY_SIZE() macro to determine the
      length of the array.  However, ARRAY_SIZE() only works when the array
      is in the same scope as the macro user.
      
      So far this hasn't been a problem.  However, to reduce duplicated
      data, a subsequent patch will move common data to a separate, shared
      file.  When this is done, ARRAY_SIZE() will no longer be usable.
      
      This patch removes ARRAY_SIZE() usage for struct omap_hwmod_addr_space
      arrays and uses a null structure member as the array terminator
      instead.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      
      
      
      
      78183f3f
  2. 21 4月, 2011 1 次提交
    • A
      OMAP2/3: hwmod: fix gpio-reset timeouts seen during bootup. · f95440ca
      Avinash.H.M 提交于
      GPIO module expects the debounce clocks to be enabled during reset. It doesn't
      reset properly and timeouts are seen, if this clock isn't enabled during
      reset. Add the HWMOD_CONTROL_OPT_CLKS_IN_RESET flags to the GPIO HWMODs, with
      which the debounce clocks are enabled during reset.
      
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Signed-off-by: NAvinash.H.M <avinashhm@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      f95440ca
  3. 20 4月, 2011 1 次提交
  4. 11 3月, 2011 3 次提交
  5. 10 3月, 2011 4 次提交
    • A
      omap: hwmod: add syss reset done flags to omap2, omap3 hwmods · d73d65fa
      Avinash.H.M 提交于
      Some of the omap2, omap3 peripherals support software reset. This
      can be done through the softreset bit in sysconfig register.
      The reset status can be checked through resetdone bit of
      sysstatus register. syss_has_reset_status is added to the hwmod
      database of peripherals which have resetdone bit in sysstatus register.
      
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Reviewed-by: NGovindraj.R <govindraj.raja@ti.com>
      Signed-off-by: NAvinash.H.M <avinashhm@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      d73d65fa
    • B
      OMAP3: hwmod data: Remove masters port links for interconnects. · 478f478b
      Benoit Cousson 提交于
      Master ports from interconnect are generating some annoying circular
      references that become tricky to handle if we have to dynamically
      remove some IP on some variant platforms.
      Since they are not used for the moment, and since we can still build
      that relation using the reverse relation (slave port from the IP
      toward master port of the interconnect), let remove them for the
      moment like it is done on OMAP4.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Sanjeev Premi <premi@ti.com>
      478f478b
    • B
      OMAP3: hwmod data: Fix incorrect SmartReflex -> L4 CORE interconnect links · b9ccf8af
      Benoit Cousson 提交于
      Commit d3442726 ("OMAP3: PM: Adding
      smartreflex hwmod data") added data that claims that the L4 CORE has
      two slave interfaces that originate from the SmartReflex modules,
      omap3_l4_core__sr1 and omap3_l4_core__sr2.  But as those two data
      structure records show, it's L4 CORE that has a master port towards
      SR1 and SR2.
      Move the incorrect data from slaves list to master list.
      
      Based on a path by Paul Walmsley <paul@pwsan.com>
      
          https://patchwork.kernel.org/patch/623171/
      
      That is based on a patch by Benoît Cousson <b-cousson@ti.com>:
      
          https://patchwork.kernel.org/patch/590561/Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NBenoît Cousson <b-cousson@ti.com>
      Cc: Sanjeev Premi <premi@ti.com>
      Cc: Thara Gopinath <thara@ti.com>
      b9ccf8af
    • P
      OMAP2/3: VENC hwmod: add OCPIF_SWSUP_IDLE flag to interface · c39bee8a
      Paul Walmsley 提交于
      According to the hwmod interface data, the DSS submodule "VENC" uses a
      clock, "dss_54m_fck"/"dss_tv_fck", which the PRCM cannot autoidle.  By
      default, the hwmod code assumes that interface clocks can be autoidled
      by the PRCM.  When the interface clock can't be autoidled by the PRCM,
      those interfaces must be marked with the OCPIF_SWSUP_IDLE flag.
      Otherwise, the "interface clock" will always have a non-zero use
      count, and the device won't enter idle.  This problem was observed on
      N8x0.
      
      Fix the immediate problem by marking the VENC interface with the
      OCPIF_SWSUP_IDLE flag.  But it's not clear that
      "dss_54m_fck"/"dss_tv_fck" is really the correct interface clock for
      VENC.  It may be that the VENC interface should use a
      hardware-autoidling interface clock.  This is the situation on OMAP4,
      which uses "l3_div_ck" as the VENC interface clock, which can be
      autoidled by the PRCM.  Clarification from TI is needed.
      
      Problem found and patch tested on N8x0 by Tony Lindgren
      <tony@atomide.com>.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Senthilvadivu Guruswamy <svadivu@ti.com>
      Cc: Sumit Semwal <sumit.semwal@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      c39bee8a
  6. 09 3月, 2011 1 次提交
  7. 08 3月, 2011 1 次提交
    • P
      OMAP: smartreflex: move plat/smartreflex.h to mach-omap2/smartreflex.h · 7328ff4d
      Paul Walmsley 提交于
      There's no reason for this header file to be in
      plat-omap/include/plat/smartreflex.h.  The hardware devices are in
      OMAP2+ SoCs only.  Leaving this header file in plat-omap causes
      problems due to cross-dependencies with other header files that should
      live in mach-omap2/.
      
      Thanks to Benoît Cousson <b-cousson@ti.com> for suggesting the removal
      of the smartreflex.h include from the OMAP3xxx hwmod data.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      7328ff4d
  8. 02 3月, 2011 2 次提交
  9. 01 3月, 2011 1 次提交
    • P
      OMAP2+: hwmod: rename some init functions · 550c8092
      Paul Walmsley 提交于
      Rename omap_hwmod_init() to omap_hwmod_register().  Rename
      omap_hwmod_late_init() to omap_hwmod_setup_all().  Also change all of
      the callers to reflect the new names.  While here, update some
      copyrights.
      
      Suggested by Tony Lindgren <tony@atomide.com>.
      
      N.B. The comment in mach-omap2/serial.c may no longer be correct, given
           recent changes in init order.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      550c8092
  10. 28 2月, 2011 1 次提交
  11. 25 2月, 2011 3 次提交
  12. 23 2月, 2011 1 次提交
  13. 18 2月, 2011 1 次提交
  14. 17 2月, 2011 2 次提交
    • H
      AM35xx: hwmod data: Add USBOTG · 273ff8c3
      Hema HK 提交于
      AM35xx hwmod data structures are populated for USBOTG with base address,
      L3 and L4 interface clocks and IRQ.
      Signed-off-by: NHema HK <hemahk@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Cousson, Benoit <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      273ff8c3
    • H
      OMAP3xxx: hwmod data: Add USBOTG · 870ea2b8
      Hema HK 提交于
      OMAP3 hwmod data structures are populated for USBOTG with base address,
      L3 and L4 interface clocks, IRQs and sysconfig register details.
      This is applicable for OMAP3430 amd OMAP3630.
      
      As per OMAP USBOTG specification, need to configure the USBOTG
      to smart idle/standby or no idle/standby during data transfer and
      force idle/standby when not in use to support retention and offmode.
      By setting HWMOD_SWSUP_SIDLE and HWMOD_SWSUP_MSTANDBY flags, framework
      will take care of configuring to no idle/standby when module is enabled
      and force idle/standby when idled.
      Signed-off-by: NHema HK <hemahk@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Cousson, Benoit <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      870ea2b8
  15. 23 12月, 2010 1 次提交
  16. 22 12月, 2010 1 次提交
    • P
      OMAP2+: wd_timer: disable on boot via hwmod postsetup mechanism · ff2516fb
      Paul Walmsley 提交于
      The OMAP watchdog timer IP blocks require a specific set of register
      writes to occur before they will be disabled[1], even if the device
      clocks appear to be disabled in the CM_*CLKEN registers.  In the MPU
      watchdog case, failure to execute this reset sequence will eventually
      cause the watchdog to reset the OMAP unexpectedly.
      
      Previously, the code to disable this watchdog was manually called from
      mach-omap2/devices.c during device initialization.  This causes the
      watchdog to be unconditionally disabled for a portion of kernel
      initialization.  This should be controllable by the board-*.c files,
      since some system integrators will want full watchdog coverage of
      kernel initialization.  Also, the watchdog disable code was not
      connected to the hwmod shutdown code.  This means that calling
      omap_hwmod_shutdown() will not, in fact, disable the watchdog, and the
      goal of omap_hwmod_shutdown() is to be able to shutdown any on-chip
      OMAP device.
      
      To resolve the latter problem, populate the pre_shutdown pointer in
      the watchdog timer hwmod classes with a function that executes the
      watchdog shutdown sequence.  This allows the hwmod code to fully
      disable the watchdog.
      
      Then, to allow some board files to support watchdog coverage
      throughout kernel initialization, add common code to mach-omap2/io.c
      to cause the MPU watchdog to be disabled on boot unless a board file
      specifically requests it to remain enabled.  Board files can do this
      by changing the watchdog timer hwmod's postsetup state between the
      omap2_init_common_infrastructure() and omap2_init_common_devices()
      function calls.
      
      1. OMAP34xx Multimedia Device Silicon Revision 3.1.x Rev. ZH
         [SWPU222H], Section 16.4.3.6, "Start/Stop Sequence for WDTs (Using
         WDTi.WSPR Register)"
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Charulatha Varadarajan <charu@ti.com>
      ff2516fb
  17. 21 12月, 2010 1 次提交
  18. 08 12月, 2010 1 次提交
  19. 10 11月, 2010 1 次提交
  20. 30 9月, 2010 2 次提交
  21. 27 7月, 2010 4 次提交
  22. 21 5月, 2010 1 次提交
  23. 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