An error occurred fetching the project authors.
  1. 10 Jul, 2011 11 commits
  2. 20 Apr, 2011 1 commit
    • Avinash.H.M's avatar
      OMAP2/3: hwmod: fix gpio-reset timeouts seen during bootup. · f95440ca
      Avinash.H.M authored
      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: default avatarAvinash.H.M <avinashhm@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      f95440ca
  3. 19 Apr, 2011 1 commit
  4. 11 Mar, 2011 3 commits
    • archit taneja's avatar
      OMAP: DSS2: Have separate irq handlers for DISPC and DSI · affe360d
      archit taneja authored
      Currently, the core DSS platform device requests for an irq line for OMAP2 and
      OMAP3. Make DISPC and DSI platform devices request for a shared IRQ line.
      
      On OMAP3, the logical OR of DSI and DISPC interrupt lines goes to the MPU. There
      is a register DSS_IRQSTATUS which tells if the interrupt came from DISPC or DSI.
      
      On OMAP2, there is no DSI, only DISPC interrupts goto the MPU. There is no
      DSS_IRQSTATUS register.
      
      Hence, it makes more sense to have separate irq handlers corresponding to the
      DSS sub modules instead of having a common handler.
      
      Since on OMAP3 the logical OR of the lines goes to MPU, the irq line is shared
      among the IRQ handlers.
      
      The hwmod irq info has been removed for DSS to DISPC and DSI for OMAP2 and OMAP3
      hwmod databases. The Probes of DISPC and DSI now request for irq handlers.
      Signed-off-by: default avatarArchit Taneja <archit@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      affe360d
    • Sumit Semwal's avatar
      OMAP2PLUS: clocks: Align DSS clock names and roles · 872462cd
      Sumit Semwal authored
      Currently, clock database has <dev, clock-name> tuples for DSS2. Because of
      this, the clock names are different across different OMAP platforms.
      
      This patch aligns the DSS2 clock names and roles across OMAP 2420, 2430, 3xxx,
      44xx platforms in the clock databases, hwmod databases for opt-clocks, and DSS
      clock handling.
      
      This ensures that clk_get/put/enable/disable APIs in DSS can use uniform role
      names.
      Signed-off-by: default avatarSumit Semwal <sumit.semwal@ti.com>
      Acked-by: default avatarPaul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      872462cd
    • Paul Walmsley's avatar
      OMAP3: wdtimer: Fix CORE idle transition · 2f4dd595
      Paul Walmsley authored
      The HW superwised smart idle for wdtimer in OMAP3 prevents
      CORE power domain idle transitions. Disable it by swithing
      to SW supervised transitions.
      
      This could be a hardware bug in the OMAP3 wdtimer2 block.
      Signed-off-by: default avatarKalle Jokiniemi <kalle.jokiniemi@nokia.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Acked-by: default avatarKevin Hilman <khilman@ti.com>
      2f4dd595
  5. 10 Mar, 2011 3 commits
  6. 09 Mar, 2011 2 commits
    • Paul Walmsley's avatar
      OMAP2/3: VENC hwmod: add OCPIF_SWSUP_IDLE flag to interface · c39bee8a
      Paul Walmsley authored
      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: default avatarPaul 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: default avatarTony Lindgren <tony@atomide.com>
      c39bee8a
    • sricharan's avatar
      OMAP3: hwmod_data: Add address space and irq in L3 hwmod. · 4bb194dc
      sricharan authored
      Add the address spaces, irqs of the l3 interconnect to the
      hwmod data. The hwmod changes are aligned with Benoit Cousson.
      Signed-off-by: default avatarsricharan <r.sricharan@ti.com>
      Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by: default avatarBenoit Cousson <b-cousson@ti.com>
      4bb194dc
  7. 08 Mar, 2011 1 commit
    • Paul Walmsley's avatar
      OMAP: smartreflex: move plat/smartreflex.h to mach-omap2/smartreflex.h · 7328ff4d
      Paul Walmsley authored
      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: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      7328ff4d
  8. 01 Mar, 2011 2 commits
  9. 28 Feb, 2011 2 commits
  10. 24 Feb, 2011 3 commits
  11. 23 Feb, 2011 1 commit
  12. 17 Feb, 2011 3 commits
  13. 22 Dec, 2010 2 commits
    • Thara Gopinath's avatar
      OMAP3: PM: Adding smartreflex hwmod data · d3442726
      Thara Gopinath authored
      This patch adds the smartreflex hwmod data for OMAP3430
      and OMAP3630.
      Signed-off-by: default avatarThara Gopinath <thara@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      d3442726
    • Paul Walmsley's avatar
      OMAP2+: wd_timer: disable on boot via hwmod postsetup mechanism · ff2516fb
      Paul Walmsley authored
      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: default avatarPaul 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
  14. 21 Dec, 2010 1 commit
  15. 08 Dec, 2010 1 commit
  16. 09 Nov, 2010 1 commit
  17. 29 Sep, 2010 2 commits