1. 23 2月, 2011 1 次提交
  2. 18 2月, 2011 1 次提交
  3. 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
  4. 23 12月, 2010 1 次提交
  5. 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
  6. 21 12月, 2010 1 次提交
  7. 08 12月, 2010 1 次提交
  8. 10 11月, 2010 1 次提交
  9. 30 9月, 2010 2 次提交
  10. 27 7月, 2010 4 次提交
  11. 21 5月, 2010 1 次提交
  12. 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