1. 22 7月, 2012 2 次提交
  2. 01 7月, 2012 1 次提交
  3. 29 6月, 2012 7 次提交
  4. 28 6月, 2012 2 次提交
  5. 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
  6. 26 6月, 2012 4 次提交
  7. 25 6月, 2012 3 次提交
    • M
      ARM: dma-mapping: fix buffer chunk allocation order · 593f4735
      Marek Szyprowski 提交于
      IOMMU-aware dma_alloc_attrs() implementation allocates buffers in
      power-of-two chunks to improve performance and take advantage of large
      page mappings provided by some IOMMU hardware. However current code, due
      to a subtle bug, allocated those chunks in the smallest-to-largest
      order, what completely killed all the advantages of using larger than
      page chunks. If a 4KiB chunk has been mapped as a first chunk, the
      consecutive chunks are not aligned correctly to the power-of-two which
      match their size and IOMMU drivers were not able to use internal
      mappings of size other than the 4KiB (largest common denominator of
      alignment and chunk size).
      
      This patch fixes this issue by changing to the correct largest-to-smallest
      chunk size allocation sequence.
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      593f4735
    • G
      m68knommu: define a local devm_clk_get() function · 19a1d332
      Greg Ungerer 提交于
      Commit f4d40de3 ("net fec: do not depend
      on grouped clocks") breaks compilation of the FEC driver for non iMX
      platforms in linux-3.5-rc1. For example when compiling for ColdFire I get:
      
            LD      vmlinux
          drivers/built-in.o: In function `fec_probe':
          fec.c:(.devinit.text+0x1e0): undefined reference to `devm_clk_get'
      
      Define a simple devm_clk_get() function for the m68knommu architecture.
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      19a1d332
    • A
      Fix typo in printed messages · 02b7d834
      Anatol Pomozov 提交于
      Coult -> Could
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      02b7d834
  8. 24 6月, 2012 3 次提交
  9. 23 6月, 2012 1 次提交
  10. 22 6月, 2012 6 次提交
    • R
      ARM: OMAP4: hwmod data: Force HDMI in no-idle while enabled · dc57aef5
      Ricardo Neri 提交于
      As per the OMAP4 documentation, audio over HDMI must be transmitted in
      no-idle mode. This patch adds the HWMOD_SWSUP_SIDLE so that omap_hwmod uses
      no-idle/force-idle settings instead of smart-idle mode.
      
      This is required as the DSS interface clock is used as functional clock
      for the HDMI wrapper audio FIFO. If no-idle mode is not used, audio could
      be choppy, have bad quality or not be audible at all.
      Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>
      [b-cousson@ti.com: Update the subject and align the .flags
      location with the script template]
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      dc57aef5
    • P
      ARM: OMAP2+: mux: fix sparse warning · 65e25976
      Paul Walmsley 提交于
      Commit bbd707ac ("ARM: omap2: use
      machine specific hook for late init") resulted in the addition of this
      sparse warning:
      
      arch/arm/mach-omap2/mux.c:791:12: warning: symbol 'omap_mux_late_init' was not declared. Should it be static?
      
      Fix by including the header file containing the prototype.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Cc: Tony Lindgren <tony@atomide.com>
      65e25976
    • P
      ARM: OMAP2+: CM: increase the module disable timeout · b8f15b7e
      Paul Walmsley 提交于
      Increase the timeout for disabling an IP block to five milliseconds.
      This is to handle the usb_host_fs idle latency, which takes almost
      four milliseconds after a host controller reset.
      
      This is the second of two patches needed to resolve the following
      boot warning:
      
      omap_hwmod: usb_host_fs: _wait_target_disable failed
      
      Thanks to Sergei Shtylyov <sshtylyov@mvista.com> for finding
      an unrelated hunk in a previous version of this patch.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Sergei Shtylyov <sshtylyov@mvista.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      b8f15b7e
    • P
      ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks · 9a47d32d
      Paul Walmsley 提交于
      Until the OMAP4 code is converted to disable the use of the clock
      framework-based clockdomain enable/disable sequence, any clock used as
      a hwmod main_clk must have a clockdomain associated with it.  This
      patch populates some clock structure clockdomain names to resolve the
      following warnings during kernel init:
      
      omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.
      omap_hwmod: trace_clk_div_ck: missing clockdomain for trace_clk_div_ck.
      omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
      omap_hwmod: ddrphy_ck: missing clockdomain for ddrphy_ck.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      9a47d32d
    • P
      ARM: OMAP4: hwmod data: fix 32k sync timer idle modes · 252a4c54
      Paul Walmsley 提交于
      The 32k sync timer IP block target idle modes in the hwmod data are
      incorrect.  The IP block does not support any smart-idle modes.
      Update the data to reflect the correct modes.
      
      This problem was initially identified and a diff fragment posted to
      the lists by Benoît Cousson <b-cousson@ti.com>.  A patch description
      bug in the first version was also identified by Benoît.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      252a4c54
    • D
      ARM: OMAP4+: hwmod: fix issue causing IPs not going back to Smart-Standby · 561038f0
      Djamil Elaidi 提交于
      If an IP is configured in Smart-Standby-Wakeup, when disabling wakeup feature the
      IP will not go back to Smart-Standby, but will remain in Smart-Standby-Wakeup.
      Signed-off-by: NDjamil Elaidi <d-elaidi@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      561038f0
  11. 21 6月, 2012 9 次提交