linux-stable.git/arch/arc/kernel/smp.c, branch linux-3.16.y Linux kernel stable tree ARC: [SMP] Fix IPI IRQ registration 2014-06-26T06:28:25+00:00 Noam Camus noamc@ezchip.com 2013-02-28T09:07:06+00:00 7e5122190b47c2574eda26aa0bbda693b2821449 Handle it just like timer. Current request_percpu_irq() would fail on non-boot cpus and thus IRQ will remian unmasked on those cpus. [vgupta: fix changelong] Signed-off-by: Noam Camus <noamc@ezchip.com> Signed-off-by: Vineet Gupta <vgupta@synopsys.com> 
Handle it just like timer. Current request_percpu_irq() would fail on
non-boot cpus and thus IRQ will remian unmasked on those cpus.

[vgupta: fix changelong]
Signed-off-by: Noam Camus <noamc@ezchip.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARC: arc_local_timer_setup() need not pass own cpu id 2014-06-03T07:56:52+00:00 Vineet Gupta vgupta@synopsys.com 2014-05-08T08:36:38+00:00 2d4899f6bddfbeb88c01f2ec28f977e0d8c8d369 Signed-off-by: Vineet Gupta <vgupta@synopsys.com> 
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARC: [SMP] optimize IPI send and receive 2013-12-23T06:35:04+00:00 Vineet Gupta vgupta@synopsys.com 2013-11-28T08:27:54+00:00 d8e8c7dda11f5d5cf90495f2e89d917a83509bc0 * Don't send an IPI if receiver already has a pending IPI. Atomically piggyback the new msg with pending msg. * IPI receiver looping on xchg() not required References: https://lkml.org/lkml/2013/11/25/232 Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Vineet Gupta <vgupta@synopsys.com> 
* Don't send an IPI if receiver already has a pending IPI.
  Atomically piggyback the new msg with pending msg.

* IPI receiver looping on xchg() not required

References: https://lkml.org/lkml/2013/11/25/232
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARC: [SMP] simplify IPI code 2013-12-23T06:35:04+00:00 Vineet Gupta vgupta@synopsys.com 2013-11-26T09:53:44+00:00 f2a4aa5646687f9a51616581221b1d348590d47e * ipi_data is just a word, no need to keep it as struct * find_next_bit() not needed to loop thru a 32bit word, ffs suffices 
* ipi_data is just a word, no need to keep it as struct

* find_next_bit() not needed to loop thru a 32bit word, ffs suffices
ARC: [SMP] cpu halt interface doesn't need "self" cpu-id 2013-12-23T06:35:04+00:00 Vineet Gupta vgupta@synopsys.com 2013-11-25T09:18:39+00:00 53dc110c97436dcf2a758091c98093657116e91c Signed-off-by: Vineet Gupta <vgupta@synopsys.com> 
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARC: [SMP] IPI ACK interface doesn't need "self" cpu-id 2013-12-23T06:35:04+00:00 Vineet Gupta vgupta@synopsys.com 2013-11-25T09:07:14+00:00 ccdaa6e0c86d8f48bf87439e4d6942b7a3e58899 The interface is confusing, it feels like we are getting "sender" info, whereas it is the "receiver", which can very well be retrived by smp_processor_id(), if need be. Signed-off-by: Vineet Gupta <vgupta@synopsys.com> 
The interface is confusing, it feels like we are getting "sender" info,
whereas it is the "receiver", which can very well be retrived by
smp_processor_id(), if need be.

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARC: [SMP] cpumask not needed in IPI send path 2013-12-23T06:35:04+00:00 Vineet Gupta vgupta@synopsys.com 2013-11-25T07:29:03+00:00 ddf84433f411b612e935a6719ee395bb9dd2221f The current IPI sending callstack needlessly involves cpumask. arch_send_call_function_single_ipi(cpu) / smp_send_reschedule(cpu) ipi_send_msg(cpumask_of(cpu)) --> [cpu to cpumask] plat_smp_ops.ipi_send(callmap) for_each_cpu(callmap) --> [cpuask to cpu] do_plat_specific_ipi_PER_CPU Given that current backends are not capable of 1:N IPIs, lets simplify the interface for now, by keeping "a" cpu all along. Signed-off-by: Vineet Gupta <vgupta@synopsys.com> 
The current IPI sending callstack needlessly involves cpumask.

   arch_send_call_function_single_ipi(cpu) / smp_send_reschedule(cpu)
      ipi_send_msg(cpumask_of(cpu))	--> [cpu to cpumask]
         plat_smp_ops.ipi_send(callmap)
            for_each_cpu(callmap)	--> [cpuask to cpu]
               do_plat_specific_ipi_PER_CPU

Given that current backends are not capable of 1:N IPIs, lets simplify
the interface for now, by keeping "a" cpu all along.

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
smp, ARC: kill SMP single function call interrupt 2013-11-07T09:04:31+00:00 Jiang Liu jiang.liu@huawei.com 2013-09-11T16:07:07+00:00 06b93c347c93d53f5cd76c3efa277ea114cb2000 Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic similar to smp_call_function_single()" has unified the way to handle single and multiple cross-CPU function calls. Now only one interrupt is needed for architecture specific code to support generic SMP function call interfaces, so kill the redundant single function call interrupt. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Cc: Jiang Liu <liuj97@gmail.com> Signed-off-by: Vineet Gupta <vgupta@synopsys.com> 
Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic
similar to smp_call_function_single()" has unified the way to handle
single and multiple cross-CPU function calls. Now only one interrupt
is needed for architecture specific code to support generic SMP function
call interfaces, so kill the redundant single function call interrupt.

Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Cc: Jiang Liu <liuj97@gmail.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARC: [SMP] TLB flush 2013-11-06T05:11:45+00:00 Vineet Gupta vgupta@synopsys.com 2013-10-27T09:19:02+00:00 5ea72a90261552ed5fdca35239feb6cba498301e - Add mm_cpumask setting (aggregating only, unlike some other arches) used to restrict the TLB flush cross-calling - cross-calling versions of TLB flush routines (thanks to Noam) Signed-off-by: Noam Camus <noamc@ezchip.com> Signed-off-by: Vineet Gupta <vgupta@synopsys.com> 
- Add mm_cpumask setting (aggregating only, unlike some other arches)
  used to restrict the TLB flush cross-calling

- cross-calling versions of TLB flush routines (thanks to Noam)

Signed-off-by: Noam Camus <noamc@ezchip.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARC: use __weak instead of __attribute__((weak)) 2013-11-06T05:10:37+00:00 Vineet Gupta vgupta@synopsys.com 2013-10-31T08:23:54+00:00 064a6269245655b15054ad9783bca9bfd8dc1f9e Signed-off-by: Vineet Gupta <vgupta@synopsys.com> 
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>