1. 08 11月, 2011 3 次提交
    • A
      ARM: OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in bootloader · b923d40d
      Archit Taneja 提交于
      Resetting DISPC when a DISPC output is enabled causes the DSS to go into an
      inconsistent state. Thus if the bootloader has enabled a display, the hwmod code
      cannot reset the DISPC module just like that, but the outputs need to be
      disabled first.
      
      Add function dispc_disable_outputs() which disables all active overlay manager
      and ensure all frame transfers are completed.
      
      Modify omap_dss_reset() to call this function and clear DSS_CONTROL,
      DSS_SDI_CONTROL and DSS_PLL_CONTROL so that DSS is in a clean state when the
      DSS2 driver starts.
      
      This resolves the hang issue(caused by a L3 error during boot) seen on the
      beagle board C3, which has a factory bootloader that enables display. The issue
      is resolved with this patch.
      
      Thanks to Tomi and Sricharan for some additional testing.
      Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Tested-by: NR, Sricharan <r.sricharan@ti.com>
      Signed-off-by: NArchit Taneja <archit@ti.com>
      [paul@pwsan.com: restructured code, removed omap_{read,write}l(), removed
       cpu_is_omap*() calls and converted to dev_attr]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      b923d40d
    • T
      ARM: OMAP2xxx: HWMOD: fix DSS clock data · b8ac10d8
      Tomi Valkeinen 提交于
      The OMAP2xxx HWMOD data currently contains two errors with DSS clocks:
      
      - dss_rfbi is missing ick opt-clock, which is needed for RFBI to
        calculate timings
      
      - dss_venc's interface and main clocks are wrong, causing VENC to fail
        to start
      
      These problems were temporarily fixed with a DSS patch
      9ede365a ("HACK: OMAP: DSS2: clk hack
      for OMAP2/3"), which can be reverted after this patch (and the similar
      patches for other OMAPs).
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      b8ac10d8
    • T
      ARM: OMAP2xxx: HWMOD: Fix DSS reset · 1258ea59
      Tomi Valkeinen 提交于
      DSS needs all DSS clocks to be enabled to be able to finish reset
      properly. Before v3.1-rc1 the omapdss driver was managing clocks and
      resets correctly. However, when omapdss started using runtime PM at
      v3.1-rc1, the responsibility for the reset moved to HWMOD framework.
      
      HWMOD framework does not currently enable all the DSS clocks when
      resetting the DSS hardware. This hasn't caused any problems so far, but
      we may just have been lucky.
      
      This patch sets HWMOD_CONTROL_OPT_CLKS_IN_RESET for dss_core in OMAP2xxx
      HWMOD data, fixing the issue.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      [paul@pwsan.com: merged duplicate .flags fields]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      1258ea59
  2. 22 9月, 2011 1 次提交
  3. 15 9月, 2011 1 次提交
    • P
      OMAP2+: hwmod: remove OMAP_CHIP* · d6504acd
      Paul Walmsley 提交于
      At Tony's request, remove the OMAP_CHIP* flags from the hwmod data, and
      replace it instead with chip family, variant, and ES level-specific lists
      of hwmods to register.
      
      Thanks to Gražvydas Ignotas <notasas@gmail.com> for finding a bug in the
      AM3517/3505 support, and for other review comments.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Gražvydas Ignotas <notasas@gmail.com>
      d6504acd
  4. 05 9月, 2011 1 次提交
    • P
      OMAP2430: hwmod: musb: add missing terminator to omap2430_usbhsotg_addrs[] · 10167873
      Paul Walmsley 提交于
      Add a missing array terminator to omap2430_usbhsotg_addrs[].  Without
      this terminator, the omap_hwmod resource building code runs off the
      end of the array, resulting in at least this error -- if not worse
      behavior:
      
      [    0.578002] musb-omap2430: failed to claim resource 4
      [    0.583465] omap_device: musb-omap2430: build failed (-16)
      [    0.589294] Could not build omap_device for musb-omap2430 usb_otg_hs
      
      This should have been part of commit
      78183f3f ("omap_hwmod: use a null
      structure record to terminate omap_hwmod_addr_space arrays") but was
      evidently missed.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      10167873
  5. 10 7月, 2011 11 次提交
  6. 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
  7. 20 4月, 2011 1 次提交
  8. 31 3月, 2011 1 次提交
  9. 11 3月, 2011 1 次提交
    • A
      OMAP: DSS2: Have separate irq handlers for DISPC and DSI · affe360d
      archit taneja 提交于
      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: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      affe360d
  10. 10 3月, 2011 2 次提交
    • 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
    • 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
  11. 02 3月, 2011 2 次提交
  12. 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
  13. 28 2月, 2011 1 次提交
  14. 25 2月, 2011 2 次提交
  15. 23 2月, 2011 1 次提交
  16. 18 2月, 2011 1 次提交
  17. 17 2月, 2011 1 次提交
    • H
      OMAP2430: hwmod data: Add USBOTG · 44d02acf
      Hema HK 提交于
      OMAP2430 hwmod data structures are populated with base address, L3 and L4
      interface clocks, IRQs and sysconfig register details.
      
      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 off-mode.
      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 suspended.
      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>
      44d02acf
  18. 22 12月, 2010 2 次提交
    • B
      OMAP2430: hwmod data: Use common dev_attr for i2c1 and i2c2 · 50ebb777
      Benoit Cousson 提交于
      Since i2c1 and i2c2 are using the same data, remove the two previous
      instances and use a common i2c_dev_attr one.
      
      Moreover, that will fix the following warning:
      arch/arm/mach-omap2/omap_hwmod_2430_data.c:485:
      warning: 'i2c_dev_attr' defined but not used
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Acked-by: NRajendra Nayak <rnayak@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Charulatha V <charu@ti.com>
      50ebb777
    • 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
  19. 21 12月, 2010 2 次提交
  20. 08 12月, 2010 1 次提交
  21. 10 11月, 2010 1 次提交
  22. 30 9月, 2010 2 次提交