1. 27 7月, 2012 3 次提交
  2. 25 7月, 2012 4 次提交
  3. 13 7月, 2012 4 次提交
  4. 12 7月, 2012 2 次提交
  5. 09 7月, 2012 1 次提交
    • K
      ARM: OMAP2+: omap2plus_defconfig: EHCI driver is not stable, disable it · 06b4ba52
      Kevin Hilman 提交于
      The EHCI driver is not stable enough to be enabled by default.  In v3.5,
      it has at least the following problems:
      
      - warning dump during bootup
      - hang during suspend
      - prevents CORE powerdomain from entering retention during idle (even
        when no USB devices connected.)
      
      This demonstrates that this driver has not been thoroughly tested and
      therfore should not be enabled in the default defconfig.
      
      In addition, the problems above cause new PM regressions which need be
      addressed before this driver should be enabled in the default
      defconfig.
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      06b4ba52
  6. 07 7月, 2012 3 次提交
  7. 06 7月, 2012 1 次提交
    • P
      ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer · 006c7f18
      Paul Walmsley 提交于
      Kevin discovered that commit c8d82ff6
      ("ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod
      database") broke CORE idle on OMAP3.  This prevents device low power
      states.
      
      The root cause is that the 32K sync timer IP block does not support
      smart-idle mode[1], and so the hwmod code keeps the IP block in
      no-idle mode while it is active.  This in turn prevents the WKUP
      clockdomain from transitioning to idle.  There is a hardcoded sleep
      dependency that prevents the CORE_L3 and CORE_CM clockdomains from
      transitioning to idle when the WKUP clockdomain is active[2], so the
      chip cannot enter any device low power states.
      
      It turns out that there is no need to take the 32k sync timer out of
      idle.  The IP block itself probably does not have any native idle
      handling at all, due to its simplicity.  Furthermore, the PRCM will
      never request target idle for this IP block while the kernel is
      running, due to the sleep dependency that prevents the WKUP
      clockdomain from idling while the CORE_L3 clockdomain is active.  So
      we can safely leave the 32k sync timer in target-force-idle mode, even
      while we continue to access it.
      
      This workaround is implemented by defining a new clockdomain flag,
      CLKDM_ACTIVE_WITH_MPU, that indicates that the clockdomain is
      guaranteed to be active whenever the MPU is inactive.  If an IP
      block's main functional clock exists inside this clockdomain, and the
      IP block does not support smart-idle modes, then the hwmod code will
      place the IP block into target force-idle mode even when enabled.  The
      WKUP clockdomains on OMAP3/4 are marked with this flag.  (On OMAP2xxx,
      no OCP header existed on the 32k sync timer.)   Other clockdomains also
      should be marked with this flag, but those changes are deferred until
      a later merge window, to create a minimal fix.
      
      Another theoretically clean fix for this problem would be to implement
      PM runtime-based control for 32k sync timer accesses.  These PM
      runtime calls would need to located in a custom clocksource, since the
      32k sync timer is currently used as an MMIO clocksource.  But in
      practice, there would be little benefit to doing so; and there would
      be some cost, due to the addition of unnecessary lines of code and the
      additional CPU overhead of the PM runtime and hwmod code - unnecessary
      in this case.
      
      Another possible fix would have been to modify the pm34xx.c code to
      force the IP block idle before entering WFI.  But this would not have
      been an acceptable approach: we are trying to remove this type of
      centralized IP block idle control from the PM code.
      
      This patch is a collaboration between Kevin Hilman <khilman@ti.com>
      and Paul Walmsley <paul@pwsan.com>.
      
      Thanks to Vaibhav Hiremath <hvaibhav@ti.com> for providing comments on
      an earlier version of this patch.  Thanks to Tero Kristo
      <t-kristo@ti.com> for identifying a bug in an earlier version of this
      patch.  Thanks to Benoît Cousson <b-cousson@ti.com> for identifying
      some bugs in several versions of this patch and for implementation
      comments.
      
      References:
      
      1. Table 16-96 "REG_32KSYNCNT_SYSCONFIG" of the OMAP34xx TRM Rev. ZU
         (SWPU223U), available from:
         http://www.ti.com/pdfs/wtbu/OMAP34x_ES3.1.x_PUBLIC_TRM_vzU.zip
      
      2. Table 4-72 "Sleep Dependencies" of the OMAP34xx TRM Rev. ZU
         (SWPU223U)
      
      3. ibid.
      
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Vaibhav Hiremath <hvaibhav@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      Tested-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      006c7f18
  8. 05 7月, 2012 9 次提交
  9. 04 7月, 2012 5 次提交
  10. 02 7月, 2012 3 次提交
  11. 01 7月, 2012 3 次提交
  12. 27 6月, 2012 2 次提交
    • J
      ARM: OMAP4470: Fix OMAP4470 boot failure · e90b833e
      Jon Hunter 提交于
      OMAP4470 currently fails to boot, printing various messages such as ...
      
      omap_hwmod: mpu: cannot clk_get main_clk dpll_mpu_m2_ck
      omap_hwmod: mpu: cannot _init_clocks
      ------------[ cut here ]------------
      WARNING: at arch/arm/mach-omap2/omap_hwmod.c:2062 _init+0x2a0/0x2e4()
      omap_hwmod: mpu: couldn't init clocks
      Modules linked in:
      [<c001c7fc>] (unwind_backtrace+0x0/0xf4) from [<c0043c64>] (warn_slowpath_common+0x4c/0x64)
      [<c0043c64>] (warn_slowpath_common+0x4c/0x64) from [<c0043d10>] (warn_slowpath_fmt+0x30/0x40)
      [<c0043d10>] (warn_slowpath_fmt+0x30/0x40) from [<c0674208>] (_init+0x2a0/0x2e4)
      [<c0674208>] (_init+0x2a0/0x2e4) from [<c067428c>] (omap_hwmod_setup_one+0x40/0x60)
      [<c067428c>] (omap_hwmod_setup_one+0x40/0x60) from [<c0674280>] (omap_hwmod_setup_one+0x34/0x60)
      [<c0674280>] (omap_hwmod_setup_one+0x34/0x60) from [<c06726f4>] (omap_dm_timer_init_one+0x30/0x250)
      [<c06726f4>] (omap_dm_timer_init_one+0x30/0x250) from [<c0672930>] (omap2_gp_clockevent_init+0x1c/0x108)
      [<c0672930>] (omap2_gp_clockevent_init+0x1c/0x108) from [<c0672c60>] (omap4_timer_init+0x10/0x5c)
      [<c0672c60>] (omap4_timer_init+0x10/0x5c) from [<c066c418>] (time_init+0x20/0x30)
      [<c066c418>] (time_init+0x20/0x30) from [<c0668814>] (start_kernel+0x1b0/0x304)
      [<c0668814>] (start_kernel+0x1b0/0x304) from [<80008044>] (0x80008044)
      ---[ end trace 1b75b31a2719ed1c ]---
      
      The problem is that currently none of the clocks are being registered for
      OMAP4470 devices and so on boot-up no clocks can be found and the kernel panics.
      
      This fix allows the kernel to boot without failure using a simple RAMDISK file
      system on OMAP4470 blaze board.
      
      Per feedback from Paul and Benoit the 4470 clock data is incomplete for new
      modules such as the 2D graphics block that has been added to the 4470.
      Therefore add a warning to indicate that the clock data is incomplete.
      
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      [tony@atomide.com: updated comments]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      e90b833e
    • S
      ARM: EXYNOS: Fix EXYNOS_DEV_DMA Kconfig entry · 58c553d4
      Sachin Kamat 提交于
      Commit 20ef9e08 ("ARM: EXYNOS: Support DMA for EXYNOS5250 SoC")
      renamed EXYNOS4_DEV_DMA to EXYNOS_DEV_DMA. But some machine entries
      still had EXYNOS4_DEV_DMA. Changed them to EXYNOS_DEV_DMA.
      Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
      Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      58c553d4