1. 16 10月, 2013 6 次提交
  2. 15 10月, 2013 1 次提交
  3. 14 10月, 2013 2 次提交
    • L
      ARM: integrator: deactivate timer0 on the Integrator/CP · 29114fd7
      Linus Walleij 提交于
      This fixes a long-standing Integrator/CP regression from
      commit 870e2928
      "ARM: integrator-cp: convert use CLKSRC_OF for timer init"
      
      When this code was introduced, the both aliases pointing the
      system to use timer1 as primary (clocksource) and timer2
      as secondary (clockevent) was ignored, and the system would
      simply use the first two timers found as clocksource and
      clockevent.
      
      However this made the system timeline accelerate by a
      factor x25, as it turns out that the way the clocking
      actually works (totally undocumented and found after some
      trial-and-error) is that timer0 runs @ 25MHz and timer1
      and timer2 runs @ 1MHz. Presumably this divider setting
      is a boot-on default and configurable albeit the way to
      configure it is not documented.
      
      So as a quick fix to the problem, let's mark timer0 as
      disabled, so the code will chose timer1 and timer2 as it
      used to.
      
      This also deletes the two aliases for the primary and
      secondary timer as they have been superceded by the
      auto-selection
      
      Cc: stable@vger.kernel.org
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      29114fd7
    • Y
      ARM: exynos: dts: Update 5250 arch timer node with clock frequency · 4d594dd3
      Yuvaraj Kumar C D 提交于
      Without the "clock-frequency" property in arch timer node, could able
      to see the below crash dump.
      
      [<c0014e28>] (unwind_backtrace+0x0/0xf4) from [<c0011808>] (show_stack+0x10/0x14)
      [<c0011808>] (show_stack+0x10/0x14) from [<c036ac1c>] (dump_stack+0x7c/0xb0)
      [<c036ac1c>] (dump_stack+0x7c/0xb0) from [<c01ab760>] (Ldiv0_64+0x8/0x18)
      [<c01ab760>] (Ldiv0_64+0x8/0x18) from [<c0062f60>] (clockevents_config.part.2+0x1c/0x74)
      [<c0062f60>] (clockevents_config.part.2+0x1c/0x74) from [<c0062fd8>] (clockevents_config_and_register+0x20/0x2c)
      [<c0062fd8>] (clockevents_config_and_register+0x20/0x2c) from [<c02b8e8c>] (arch_timer_setup+0xa8/0x134)
      [<c02b8e8c>] (arch_timer_setup+0xa8/0x134) from [<c04b47b4>] (arch_timer_init+0x1f4/0x24c)
      [<c04b47b4>] (arch_timer_init+0x1f4/0x24c) from [<c04b40d8>] (clocksource_of_init+0x34/0x58)
      [<c04b40d8>] (clocksource_of_init+0x34/0x58) from [<c049ed8c>] (time_init+0x20/0x2c)
      [<c049ed8c>] (time_init+0x20/0x2c) from [<c049b95c>] (start_kernel+0x1e0/0x39c)
      
      THis is because the Exynos u-boot, for example on the Chromebooks, doesn't set
      up the CNTFRQ register as expected by arch_timer. Instead, we have to specify
      the frequency in the device tree like this.
      Signed-off-by: NYuvaraj Kumar C D <yuvaraj.cd@samsung.com>
      [olof: Changed subject, added comment, elaborated on commit message]
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      4d594dd3
  4. 09 10月, 2013 2 次提交
    • T
      ARM: dts: Fix pinctrl mask for omap3 · d623a0e1
      Tony Lindgren 提交于
      The wake-up interrupt bit is available on omap3/4/5 processors
      unlike what we claim. Without fixing it we cannot use it on
      omap3 and the system configured for wake-up events will just
      hang on wake-up.
      
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: Benoît Cousson <bcousson@baylibre.com>
      Cc: devicetree@vger.kernel.org
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      d623a0e1
    • N
      ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree · 016c12d2
      Nishanth Menon 提交于
      SoC family definitions at the moment are reactive to board needs
      as a result, beagle-xm would matchup with ti,omap3 which invokes
      omap3430_init_early instead of omap3630_init_early. Obviously, this is
      the wrong behavior.
      
      With clock node dts conversion, we get the following warnings before
      system hangs as a result and 3630 based platforms fails to boot
      (uart4 clocks are only present in OMAP3630 and not present in
      OMAP3430):
      
      ...
      omap_hwmod: uart4: cannot clk_get main_clk uart4_fck
      omap_hwmod: uart4: cannot _init_clocks
      
      WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2434
      _init+0x6c/0x80()
      omap_hwmod: uart4: couldn't init clocks
      ...
      
      WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
      _enable+0x254/0x280()
      omap_hwmod: timer12: enabled state can only be entered from
      initialized, idle, or disabled state
      ...
      
      WARNING: CPU: 0 PID: 46 at arch/arm/mach-omap2/omap_hwmod.c:2224
      _idle+0xd4/0xf8()
      omap_hwmod: timer12: idle state can only be entered from enabled state
      
      WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
      _enable+0x254/0x280()
      omap_hwmod: uart4: enabled state can only be entered from
      initialized, idle, or disabled state
      
      So, add specific compatiblity for 3630 to allow match for Beagle-XM
      platform.
      Signed-off-by: NNishanth Menon <nm@ti.com>
      [tony@atomide.com: left out ti,omap343x, updated comments]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      016c12d2
  5. 04 10月, 2013 2 次提交
  6. 01 10月, 2013 7 次提交
  7. 30 9月, 2013 2 次提交
  8. 28 9月, 2013 1 次提交
  9. 26 9月, 2013 1 次提交
  10. 25 9月, 2013 2 次提交
  11. 22 9月, 2013 2 次提交
  12. 20 9月, 2013 1 次提交
  13. 19 9月, 2013 5 次提交
  14. 18 9月, 2013 3 次提交
  15. 17 9月, 2013 3 次提交