1. 18 4月, 2014 2 次提交
  2. 22 3月, 2014 1 次提交
    • G
      clocksource: CMT, MTU2, TMU and STI should depend on GENERIC_CLOCKEVENTS · 87291a92
      Geert Uytterhoeven 提交于
      If GENERIC_CLOCKEVENTS=n:
      
      drivers/clocksource/sh_cmt.c:54:28: error: field 'ced' has incomplete type
      drivers/clocksource/sh_cmt.c: In function 'sh_cmt_interrupt':
      drivers/clocksource/sh_cmt.c:407:23: error: 'CLOCK_EVT_MODE_ONESHOT' undeclared (first use in this function)
      
      drivers/clocksource/sh_mtu2.c:44:28: error: field 'ced' has incomplete type
      drivers/clocksource/sh_mtu2.c: In function 'ced_to_sh_mtu2':
      drivers/clocksource/sh_mtu2.c:184:70: warning: initialization from incompatible pointer type [enabled by default]
      drivers/clocksource/sh_mtu2.c: At top level:
      drivers/clocksource/sh_mtu2.c:188:16: warning: 'enum clock_event_mode' declared inside parameter list [enabled by default]
      
      drivers/clocksource/sh_tmu.c:45:28: error: field 'ced' has incomplete type
      drivers/clocksource/sh_tmu.c: In function 'sh_tmu_interrupt':
      drivers/clocksource/sh_tmu.c:207:21: error: 'CLOCK_EVT_MODE_ONESHOT' undeclared (first use in this function)
      
      drivers/clocksource/em_sti.c:44:28: error: field 'ced' has incomplete type
      drivers/clocksource/em_sti.c: In function 'ced_to_em_sti':
      drivers/clocksource/em_sti.c:251:69: warning: initialization from incompatible pointer type [enabled by default]
      drivers/clocksource/em_sti.c: At top level:
      drivers/clocksource/em_sti.c:255:16: warning: 'enum clock_event_mode' declared inside parameter list [enabled by default]
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Cc: Magnus Damm <damm@opensource.se>
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Link: http://lkml.kernel.org/r/1395324352-9146-1-git-send-email-geert@linux-m68k.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      87291a92
  3. 20 3月, 2014 1 次提交
    • S
      clocksource, dummy-timer: Fix CPU hotplug callback registration · 8daa127f
      Srivatsa S. Bhat 提交于
      Subsystems that want to register CPU hotplug callbacks, as well as perform
      initialization for the CPUs that are already online, often do it as shown
      below:
      
      	get_online_cpus();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	register_cpu_notifier(&foobar_cpu_notifier);
      
      	put_online_cpus();
      
      This is wrong, since it is prone to ABBA deadlocks involving the
      cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
      with CPU hotplug operations).
      
      Instead, the correct and race-free way of performing the callback
      registration is:
      
      	cpu_notifier_register_begin();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	/* Note the use of the double underscored version of the API */
      	__register_cpu_notifier(&foobar_cpu_notifier);
      
      	cpu_notifier_register_done();
      
      Fix the clocksource dummy-timer code by using this latter form of callback
      registration.
      
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8daa127f
  4. 12 3月, 2014 11 次提交
  5. 06 3月, 2014 1 次提交
  6. 14 2月, 2014 1 次提交
  7. 12 2月, 2014 1 次提交
  8. 07 2月, 2014 1 次提交
  9. 06 2月, 2014 1 次提交
  10. 05 2月, 2014 1 次提交
  11. 01 2月, 2014 1 次提交
  12. 19 1月, 2014 1 次提交
  13. 30 12月, 2013 1 次提交
    • S
      clocksource: cadence_ttc: Fix mutex taken inside interrupt context · c1dcc927
      Soren Brinkmann 提交于
      When the kernel is compiled with:
      CONFIG_HIGH_RES_TIMERS=no
      CONFIG_HZ_PERIODIC=yes
      CONFIG_DEBUG_ATOMIC_SLEEP=yes
      
      The following WARN appears:
      
      WARNING: CPU: 1 PID: 0 at linux/kernel/mutex.c:856 mutex_trylock+0x70/0x1fc()
      DEBUG_LOCKS_WARN_ON(in_interrupt())
      Modules linked in:
      CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.12.0-xilinx-dirty #93
      [<c0014a78>] (unwind_backtrace+0x0/0x11c) from [<c0011b6c>] (show_stack+0x10/0x14)
      [<c0011b6c>] (show_stack+0x10/0x14) from [<c039120c>] (dump_stack+0x7c/0xc0)
      [<c039120c>] (dump_stack+0x7c/0xc0) from [<c001fda4>] (warn_slowpath_common+0x60/0x84)
      [<c001fda4>] (warn_slowpath_common+0x60/0x84) from [<c001fe48>] (warn_slowpath_fmt+0x2c/0x3c)
      [<c001fe48>] (warn_slowpath_fmt+0x2c/0x3c) from [<c0392658>] (mutex_trylock+0x70/0x1fc)
      [<c0392658>] (mutex_trylock+0x70/0x1fc) from [<c02dfc08>] (clk_prepare_lock+0xc/0xe4)
      [<c02dfc08>] (clk_prepare_lock+0xc/0xe4) from [<c02e099c>] (clk_get_rate+0xc/0x44)
      [<c02e099c>] (clk_get_rate+0xc/0x44) from [<c02d0394>] (ttc_set_mode+0x34/0x78)
      [<c02d0394>] (ttc_set_mode+0x34/0x78) from [<c005f794>] (clockevents_set_mode+0x28/0x5c)
      [<c005f794>] (clockevents_set_mode+0x28/0x5c) from [<c00607fc>] (tick_broadcast_on_off+0x190/0x1c0)
      [<c00607fc>] (tick_broadcast_on_off+0x190/0x1c0) from [<c005f168>] (clockevents_notify+0x58/0x1ac)
      [<c005f168>] (clockevents_notify+0x58/0x1ac) from [<c02b99dc>] (cpuidle_setup_broadcast_timer+0x20/0x24)
      [<c02b99dc>] (cpuidle_setup_broadcast_timer+0x20/0x24) from [<c006cd04>] (generic_smp_call_function_single_interrupt+0)
      [<c006cd04>] (generic_smp_call_function_single_interrupt+0xe0/0x130) from [<c00138c8>] (handle_IPI+0x88/0x118)
      [<c00138c8>] (handle_IPI+0x88/0x118) from [<c0008504>] (gic_handle_irq+0x58/0x60)
      [<c0008504>] (gic_handle_irq+0x58/0x60) from [<c0012644>] (__irq_svc+0x44/0x78)
      Exception stack(0xef099fa0 to 0xef099fe8)
      9fa0: 00000001 ef092100 00000000 ef092100 ef098000 00000015 c0399f2c c0579d74
      9fc0: 0000406a 413fc090 00000000 00000000 00000000 ef099fe8 c00666ec c000f46c
      9fe0: 20000113 ffffffff
      [<c0012644>] (__irq_svc+0x44/0x78) from [<c000f46c>] (arch_cpu_idle+0x34/0x3c)
      [<c000f46c>] (arch_cpu_idle+0x34/0x3c) from [<c0053980>] (cpu_startup_entry+0xa8/0x10c)
      [<c0053980>] (cpu_startup_entry+0xa8/0x10c) from [<000085a4>] (0x85a4)
      
      We are in an interrupt context (IPI) and we are calling clk_get_rate in the
      set_mode function which in turn ends up by getting a mutex... Even if that
      does not hang, it is a potential kernel deadlock.
      
      It is not allowed to call clk_get_rate() from interrupt context. To
      avoid such calls the timer input frequency is stored in the driver's
      data struct which makes it accessible to the driver in any context.
      
      [dlezcano] completed the changelog with the WARN trace and added a more
      detailed description. Tested on zync zc702.
      Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Tested-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NSoren Brinkmann <soren.brinkmann@xilinx.com>
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      c1dcc927
  14. 20 12月, 2013 1 次提交
  15. 18 12月, 2013 1 次提交
  16. 16 12月, 2013 1 次提交
  17. 14 12月, 2013 1 次提交
  18. 11 12月, 2013 12 次提交