2009-01-07 23:14:39 +08:00
|
|
|
/*
|
2009-09-24 22:11:24 +08:00
|
|
|
* IPI management based on arch/arm/kernel/smp.c (Copyright 2002 ARM Limited)
|
2009-01-07 23:14:39 +08:00
|
|
|
*
|
2009-09-24 22:11:24 +08:00
|
|
|
* Copyright 2007-2009 Analog Devices Inc.
|
|
|
|
* Philippe Gerum <rpm@xenomai.org>
|
2009-01-07 23:14:39 +08:00
|
|
|
*
|
2009-09-24 22:11:24 +08:00
|
|
|
* Licensed under the GPL-2.
|
2009-01-07 23:14:39 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/spinlock.h>
|
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/interrupt.h>
|
|
|
|
#include <linux/cache.h>
|
|
|
|
#include <linux/profile.h>
|
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/cpu.h>
|
|
|
|
#include <linux/smp.h>
|
2009-09-21 19:51:31 +08:00
|
|
|
#include <linux/cpumask.h>
|
2009-01-07 23:14:39 +08:00
|
|
|
#include <linux/seq_file.h>
|
|
|
|
#include <linux/irq.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
|
|
|
#include <linux/slab.h>
|
2009-01-07 23:14:39 +08:00
|
|
|
#include <asm/atomic.h>
|
|
|
|
#include <asm/cacheflush.h>
|
2011-04-15 15:06:59 +08:00
|
|
|
#include <asm/irq_handler.h>
|
2009-01-07 23:14:39 +08:00
|
|
|
#include <asm/mmu_context.h>
|
|
|
|
#include <asm/pgtable.h>
|
|
|
|
#include <asm/pgalloc.h>
|
|
|
|
#include <asm/processor.h>
|
|
|
|
#include <asm/ptrace.h>
|
|
|
|
#include <asm/cpu.h>
|
2009-05-15 19:01:59 +08:00
|
|
|
#include <asm/time.h>
|
2009-01-07 23:14:39 +08:00
|
|
|
#include <linux/err.h>
|
|
|
|
|
2009-05-06 18:38:07 +08:00
|
|
|
/*
|
|
|
|
* Anomaly notes:
|
|
|
|
* 05000120 - we always define corelock as 32-bit integer in L2
|
|
|
|
*/
|
2009-01-07 23:14:39 +08:00
|
|
|
struct corelock_slot corelock __attribute__ ((__section__(".l2.bss")));
|
|
|
|
|
2010-08-05 15:49:26 +08:00
|
|
|
#ifdef CONFIG_ICACHE_FLUSH_L1
|
|
|
|
unsigned long blackfin_iflush_l1_entry[NR_CPUS];
|
|
|
|
#endif
|
|
|
|
|
2011-05-30 11:12:51 +08:00
|
|
|
struct blackfin_initial_pda __cpuinitdata initial_pda_coreb;
|
2009-01-07 23:14:39 +08:00
|
|
|
|
|
|
|
#define BFIN_IPI_RESCHEDULE 0
|
|
|
|
#define BFIN_IPI_CALL_FUNC 1
|
|
|
|
#define BFIN_IPI_CPU_STOP 2
|
|
|
|
|
|
|
|
struct blackfin_flush_data {
|
|
|
|
unsigned long start;
|
|
|
|
unsigned long end;
|
|
|
|
};
|
|
|
|
|
|
|
|
void *secondary_stack;
|
|
|
|
|
|
|
|
|
|
|
|
struct smp_call_struct {
|
|
|
|
void (*func)(void *info);
|
|
|
|
void *info;
|
|
|
|
int wait;
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
cpumask_t *waitmask;
|
2009-01-07 23:14:39 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static struct blackfin_flush_data smp_flush_data;
|
|
|
|
|
|
|
|
static DEFINE_SPINLOCK(stop_lock);
|
|
|
|
|
|
|
|
struct ipi_message {
|
|
|
|
unsigned long type;
|
|
|
|
struct smp_call_struct call_struct;
|
|
|
|
};
|
|
|
|
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
/* A magic number - stress test shows this is safe for common cases */
|
|
|
|
#define BFIN_IPI_MSGQ_LEN 5
|
|
|
|
|
|
|
|
/* Simple FIFO buffer, overflow leads to panic */
|
2009-01-07 23:14:39 +08:00
|
|
|
struct ipi_message_queue {
|
|
|
|
spinlock_t lock;
|
|
|
|
unsigned long count;
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
unsigned long head; /* head of the queue */
|
|
|
|
struct ipi_message ipi_message[BFIN_IPI_MSGQ_LEN];
|
2009-01-07 23:14:39 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static DEFINE_PER_CPU(struct ipi_message_queue, ipi_msg_queue);
|
|
|
|
|
|
|
|
static void ipi_cpu_stop(unsigned int cpu)
|
|
|
|
{
|
|
|
|
spin_lock(&stop_lock);
|
|
|
|
printk(KERN_CRIT "CPU%u: stopping\n", cpu);
|
|
|
|
dump_stack();
|
|
|
|
spin_unlock(&stop_lock);
|
|
|
|
|
2011-04-26 09:57:27 +08:00
|
|
|
set_cpu_online(cpu, false);
|
2009-01-07 23:14:39 +08:00
|
|
|
|
|
|
|
local_irq_disable();
|
|
|
|
|
|
|
|
while (1)
|
|
|
|
SSYNC();
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ipi_flush_icache(void *info)
|
|
|
|
{
|
|
|
|
struct blackfin_flush_data *fdata = info;
|
|
|
|
|
|
|
|
/* Invalidate the memory holding the bounds of the flushed region. */
|
2011-04-12 16:16:04 +08:00
|
|
|
blackfin_dcache_invalidate_range((unsigned long)fdata,
|
|
|
|
(unsigned long)fdata + sizeof(*fdata));
|
|
|
|
|
|
|
|
/* Make sure all write buffers in the data side of the core
|
|
|
|
* are flushed before trying to invalidate the icache. This
|
|
|
|
* needs to be after the data flush and before the icache
|
|
|
|
* flush so that the SSYNC does the right thing in preventing
|
|
|
|
* the instruction prefetcher from hitting things in cached
|
|
|
|
* memory at the wrong time -- it runs much further ahead than
|
|
|
|
* the pipeline.
|
|
|
|
*/
|
|
|
|
SSYNC();
|
|
|
|
|
|
|
|
/* ipi_flaush_icache is invoked by generic flush_icache_range,
|
|
|
|
* so call blackfin arch icache flush directly here.
|
|
|
|
*/
|
|
|
|
blackfin_icache_flush_range(fdata->start, fdata->end);
|
2009-01-07 23:14:39 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void ipi_call_function(unsigned int cpu, struct ipi_message *msg)
|
|
|
|
{
|
|
|
|
int wait;
|
|
|
|
void (*func)(void *info);
|
|
|
|
void *info;
|
|
|
|
func = msg->call_struct.func;
|
|
|
|
info = msg->call_struct.info;
|
|
|
|
wait = msg->call_struct.wait;
|
|
|
|
func(info);
|
2009-12-04 14:56:21 +08:00
|
|
|
if (wait) {
|
|
|
|
#ifdef __ARCH_SYNC_CORE_DCACHE
|
|
|
|
/*
|
|
|
|
* 'wait' usually means synchronization between CPUs.
|
|
|
|
* Invalidate D cache in case shared data was changed
|
|
|
|
* by func() to ensure cache coherence.
|
|
|
|
*/
|
|
|
|
resync_core_dcache();
|
|
|
|
#endif
|
2011-04-26 09:57:27 +08:00
|
|
|
cpumask_clear_cpu(cpu, msg->call_struct.waitmask);
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
}
|
2009-01-07 23:14:39 +08:00
|
|
|
}
|
|
|
|
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
/* Use IRQ_SUPPLE_0 to request reschedule.
|
|
|
|
* When returning from interrupt to user space,
|
|
|
|
* there is chance to reschedule */
|
|
|
|
static irqreturn_t ipi_handler_int0(int irq, void *dev_instance)
|
|
|
|
{
|
|
|
|
unsigned int cpu = smp_processor_id();
|
|
|
|
|
|
|
|
platform_clear_ipi(cpu, IRQ_SUPPLE_0);
|
|
|
|
return IRQ_HANDLED;
|
|
|
|
}
|
|
|
|
|
|
|
|
static irqreturn_t ipi_handler_int1(int irq, void *dev_instance)
|
2009-01-07 23:14:39 +08:00
|
|
|
{
|
2009-06-10 16:42:41 +08:00
|
|
|
struct ipi_message *msg;
|
2009-01-07 23:14:39 +08:00
|
|
|
struct ipi_message_queue *msg_queue;
|
|
|
|
unsigned int cpu = smp_processor_id();
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
unsigned long flags;
|
2009-01-07 23:14:39 +08:00
|
|
|
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
platform_clear_ipi(cpu, IRQ_SUPPLE_1);
|
2009-01-07 23:14:39 +08:00
|
|
|
|
|
|
|
msg_queue = &__get_cpu_var(ipi_msg_queue);
|
|
|
|
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
spin_lock_irqsave(&msg_queue->lock, flags);
|
|
|
|
|
|
|
|
while (msg_queue->count) {
|
|
|
|
msg = &msg_queue->ipi_message[msg_queue->head];
|
2009-01-07 23:14:39 +08:00
|
|
|
switch (msg->type) {
|
2011-04-05 23:23:39 +08:00
|
|
|
case BFIN_IPI_RESCHEDULE:
|
|
|
|
scheduler_ipi();
|
|
|
|
break;
|
2009-01-07 23:14:39 +08:00
|
|
|
case BFIN_IPI_CALL_FUNC:
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
spin_unlock_irqrestore(&msg_queue->lock, flags);
|
2009-01-07 23:14:39 +08:00
|
|
|
ipi_call_function(cpu, msg);
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
spin_lock_irqsave(&msg_queue->lock, flags);
|
2009-01-07 23:14:39 +08:00
|
|
|
break;
|
|
|
|
case BFIN_IPI_CPU_STOP:
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
spin_unlock_irqrestore(&msg_queue->lock, flags);
|
2009-01-07 23:14:39 +08:00
|
|
|
ipi_cpu_stop(cpu);
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
spin_lock_irqsave(&msg_queue->lock, flags);
|
2009-01-07 23:14:39 +08:00
|
|
|
break;
|
|
|
|
default:
|
2010-03-27 10:27:51 +08:00
|
|
|
printk(KERN_CRIT "CPU%u: Unknown IPI message 0x%lx\n",
|
|
|
|
cpu, msg->type);
|
2009-01-07 23:14:39 +08:00
|
|
|
break;
|
|
|
|
}
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
msg_queue->head++;
|
|
|
|
msg_queue->head %= BFIN_IPI_MSGQ_LEN;
|
|
|
|
msg_queue->count--;
|
2009-01-07 23:14:39 +08:00
|
|
|
}
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
spin_unlock_irqrestore(&msg_queue->lock, flags);
|
2009-01-07 23:14:39 +08:00
|
|
|
return IRQ_HANDLED;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ipi_queue_init(void)
|
|
|
|
{
|
|
|
|
unsigned int cpu;
|
|
|
|
struct ipi_message_queue *msg_queue;
|
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
msg_queue = &per_cpu(ipi_msg_queue, cpu);
|
|
|
|
spin_lock_init(&msg_queue->lock);
|
|
|
|
msg_queue->count = 0;
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
msg_queue->head = 0;
|
2009-01-07 23:14:39 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
static inline void smp_send_message(cpumask_t callmap, unsigned long type,
|
|
|
|
void (*func) (void *info), void *info, int wait)
|
2009-01-07 23:14:39 +08:00
|
|
|
{
|
|
|
|
unsigned int cpu;
|
|
|
|
struct ipi_message_queue *msg_queue;
|
|
|
|
struct ipi_message *msg;
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
unsigned long flags, next_msg;
|
2011-04-26 09:57:27 +08:00
|
|
|
cpumask_t waitmask; /* waitmask is shared by all cpus */
|
2009-01-07 23:14:39 +08:00
|
|
|
|
2011-04-26 09:57:27 +08:00
|
|
|
cpumask_copy(&waitmask, &callmap);
|
|
|
|
for_each_cpu(cpu, &callmap) {
|
2009-01-07 23:14:39 +08:00
|
|
|
msg_queue = &per_cpu(ipi_msg_queue, cpu);
|
|
|
|
spin_lock_irqsave(&msg_queue->lock, flags);
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
if (msg_queue->count < BFIN_IPI_MSGQ_LEN) {
|
|
|
|
next_msg = (msg_queue->head + msg_queue->count)
|
|
|
|
% BFIN_IPI_MSGQ_LEN;
|
|
|
|
msg = &msg_queue->ipi_message[next_msg];
|
|
|
|
msg->type = type;
|
|
|
|
if (type == BFIN_IPI_CALL_FUNC) {
|
|
|
|
msg->call_struct.func = func;
|
|
|
|
msg->call_struct.info = info;
|
|
|
|
msg->call_struct.wait = wait;
|
|
|
|
msg->call_struct.waitmask = &waitmask;
|
|
|
|
}
|
|
|
|
msg_queue->count++;
|
|
|
|
} else
|
|
|
|
panic("IPI message queue overflow\n");
|
2009-01-07 23:14:39 +08:00
|
|
|
spin_unlock_irqrestore(&msg_queue->lock, flags);
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
platform_send_ipi_cpu(cpu, IRQ_SUPPLE_1);
|
2009-01-07 23:14:39 +08:00
|
|
|
}
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
|
2009-01-07 23:14:39 +08:00
|
|
|
if (wait) {
|
2011-04-26 09:57:27 +08:00
|
|
|
while (!cpumask_empty(&waitmask))
|
2009-01-07 23:14:39 +08:00
|
|
|
blackfin_dcache_invalidate_range(
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
(unsigned long)(&waitmask),
|
|
|
|
(unsigned long)(&waitmask));
|
2009-12-04 14:56:21 +08:00
|
|
|
#ifdef __ARCH_SYNC_CORE_DCACHE
|
|
|
|
/*
|
|
|
|
* Invalidate D cache in case shared data was changed by
|
|
|
|
* other processors to ensure cache coherence.
|
|
|
|
*/
|
|
|
|
resync_core_dcache();
|
|
|
|
#endif
|
2009-01-07 23:14:39 +08:00
|
|
|
}
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
int smp_call_function(void (*func)(void *info), void *info, int wait)
|
|
|
|
{
|
|
|
|
cpumask_t callmap;
|
|
|
|
|
2010-06-25 13:55:16 +08:00
|
|
|
preempt_disable();
|
2011-04-26 09:57:27 +08:00
|
|
|
cpumask_copy(&callmap, cpu_online_mask);
|
|
|
|
cpumask_clear_cpu(smp_processor_id(), &callmap);
|
|
|
|
if (!cpumask_empty(&callmap))
|
2010-06-25 13:55:16 +08:00
|
|
|
smp_send_message(callmap, BFIN_IPI_CALL_FUNC, func, info, wait);
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
|
2010-06-25 13:55:16 +08:00
|
|
|
preempt_enable();
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
|
2009-01-07 23:14:39 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(smp_call_function);
|
|
|
|
|
|
|
|
int smp_call_function_single(int cpuid, void (*func) (void *info), void *info,
|
|
|
|
int wait)
|
|
|
|
{
|
|
|
|
unsigned int cpu = cpuid;
|
|
|
|
cpumask_t callmap;
|
|
|
|
|
|
|
|
if (cpu_is_offline(cpu))
|
|
|
|
return 0;
|
2011-04-26 09:57:27 +08:00
|
|
|
cpumask_clear(&callmap);
|
|
|
|
cpumask_set_cpu(cpu, &callmap);
|
2009-01-07 23:14:39 +08:00
|
|
|
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
smp_send_message(callmap, BFIN_IPI_CALL_FUNC, func, info, wait);
|
2009-01-07 23:14:39 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(smp_call_function_single);
|
|
|
|
|
|
|
|
void smp_send_reschedule(int cpu)
|
|
|
|
{
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
/* simply trigger an ipi */
|
2009-01-07 23:14:39 +08:00
|
|
|
if (cpu_is_offline(cpu))
|
|
|
|
return;
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
platform_send_ipi_cpu(cpu, IRQ_SUPPLE_0);
|
2009-01-07 23:14:39 +08:00
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
void smp_send_stop(void)
|
|
|
|
{
|
|
|
|
cpumask_t callmap;
|
|
|
|
|
2010-06-25 13:55:16 +08:00
|
|
|
preempt_disable();
|
2011-04-26 09:57:27 +08:00
|
|
|
cpumask_copy(&callmap, cpu_online_mask);
|
|
|
|
cpumask_clear_cpu(smp_processor_id(), &callmap);
|
|
|
|
if (!cpumask_empty(&callmap))
|
2010-06-25 13:55:16 +08:00
|
|
|
smp_send_message(callmap, BFIN_IPI_CPU_STOP, NULL, NULL, 0);
|
2009-01-07 23:14:39 +08:00
|
|
|
|
2010-06-25 13:55:16 +08:00
|
|
|
preempt_enable();
|
2009-01-07 23:14:39 +08:00
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
int __cpuinit __cpu_up(unsigned int cpu)
|
|
|
|
{
|
|
|
|
int ret;
|
2009-12-28 19:13:51 +08:00
|
|
|
static struct task_struct *idle;
|
|
|
|
|
|
|
|
if (idle)
|
|
|
|
free_task(idle);
|
2009-01-07 23:14:39 +08:00
|
|
|
|
|
|
|
idle = fork_idle(cpu);
|
|
|
|
if (IS_ERR(idle)) {
|
|
|
|
printk(KERN_ERR "CPU%u: fork() failed\n", cpu);
|
|
|
|
return PTR_ERR(idle);
|
|
|
|
}
|
|
|
|
|
|
|
|
secondary_stack = task_stack_page(idle) + THREAD_SIZE;
|
|
|
|
|
|
|
|
ret = platform_boot_secondary(cpu, idle);
|
|
|
|
|
|
|
|
secondary_stack = NULL;
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __cpuinit setup_secondary(unsigned int cpu)
|
|
|
|
{
|
|
|
|
unsigned long ilat;
|
|
|
|
|
|
|
|
bfin_write_IMASK(0);
|
|
|
|
CSYNC();
|
|
|
|
ilat = bfin_read_ILAT();
|
|
|
|
CSYNC();
|
|
|
|
bfin_write_ILAT(ilat);
|
|
|
|
CSYNC();
|
|
|
|
|
|
|
|
/* Enable interrupt levels IVG7-15. IARs have been already
|
|
|
|
* programmed by the boot CPU. */
|
2008-11-18 17:48:22 +08:00
|
|
|
bfin_irq_flags |= IMASK_IVG15 |
|
2009-01-07 23:14:39 +08:00
|
|
|
IMASK_IVG14 | IMASK_IVG13 | IMASK_IVG12 | IMASK_IVG11 |
|
|
|
|
IMASK_IVG10 | IMASK_IVG9 | IMASK_IVG8 | IMASK_IVG7 | IMASK_IVGHW;
|
|
|
|
}
|
|
|
|
|
|
|
|
void __cpuinit secondary_start_kernel(void)
|
|
|
|
{
|
|
|
|
unsigned int cpu = smp_processor_id();
|
|
|
|
struct mm_struct *mm = &init_mm;
|
|
|
|
|
|
|
|
if (_bfin_swrst & SWRST_DBL_FAULT_B) {
|
|
|
|
printk(KERN_EMERG "CoreB Recovering from DOUBLE FAULT event\n");
|
|
|
|
#ifdef CONFIG_DEBUG_DOUBLEFAULT
|
2011-05-30 11:12:51 +08:00
|
|
|
printk(KERN_EMERG " While handling exception (EXCAUSE = %#x) at %pF\n",
|
|
|
|
initial_pda_coreb.seqstat_doublefault & SEQSTAT_EXCAUSE,
|
|
|
|
initial_pda_coreb.retx_doublefault);
|
|
|
|
printk(KERN_NOTICE " DCPLB_FAULT_ADDR: %pF\n",
|
|
|
|
initial_pda_coreb.dcplb_doublefault_addr);
|
|
|
|
printk(KERN_NOTICE " ICPLB_FAULT_ADDR: %pF\n",
|
|
|
|
initial_pda_coreb.icplb_doublefault_addr);
|
2009-01-07 23:14:39 +08:00
|
|
|
#endif
|
|
|
|
printk(KERN_NOTICE " The instruction at %pF caused a double exception\n",
|
2011-05-30 11:12:51 +08:00
|
|
|
initial_pda_coreb.retx);
|
2009-01-07 23:14:39 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We want the D-cache to be enabled early, in case the atomic
|
|
|
|
* support code emulates cache coherence (see
|
|
|
|
* __ARCH_SYNC_CORE_DCACHE).
|
|
|
|
*/
|
|
|
|
init_exception_vectors();
|
|
|
|
|
|
|
|
local_irq_disable();
|
|
|
|
|
|
|
|
/* Attach the new idle task to the global mm. */
|
|
|
|
atomic_inc(&mm->mm_users);
|
|
|
|
atomic_inc(&mm->mm_count);
|
|
|
|
current->active_mm = mm;
|
|
|
|
|
|
|
|
preempt_disable();
|
|
|
|
|
|
|
|
setup_secondary(cpu);
|
|
|
|
|
2009-12-02 15:58:12 +08:00
|
|
|
platform_secondary_init(cpu);
|
|
|
|
|
2009-12-28 18:21:49 +08:00
|
|
|
/* setup local core timer */
|
|
|
|
bfin_local_timer_setup();
|
|
|
|
|
2009-01-07 23:14:39 +08:00
|
|
|
local_irq_enable();
|
|
|
|
|
2010-09-07 18:08:36 +08:00
|
|
|
bfin_setup_caches(cpu);
|
|
|
|
|
2009-12-02 15:58:12 +08:00
|
|
|
/*
|
|
|
|
* Calibrate loops per jiffy value.
|
|
|
|
* IRQs need to be enabled here - D-cache can be invalidated
|
|
|
|
* in timer irq handler, so core B can read correct jiffies.
|
|
|
|
*/
|
|
|
|
calibrate_delay();
|
2009-01-07 23:14:39 +08:00
|
|
|
|
|
|
|
cpu_idle();
|
|
|
|
}
|
|
|
|
|
|
|
|
void __init smp_prepare_boot_cpu(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
void __init smp_prepare_cpus(unsigned int max_cpus)
|
|
|
|
{
|
|
|
|
platform_prepare_cpus(max_cpus);
|
|
|
|
ipi_queue_init();
|
Blackfin: SMP: rewrite IPI handling to avoid memory allocation
Currently, sending an interprocessor interrupt (IPI) requires building up
a message dynamically which means memory allocation. But often times, we
will want to send an IPI in low level contexts where allocation is not
possible which may lead to a panic(). So create a per-cpu static array
for the message queue and use that instead.
Further, while we have two supplemental interrupts, we are currently only
using one of them. So use the second one for the most common IPI message
of all -- smp_send_reschedule(). This avoids ugly contention for locks
which in turn would require an IPI message ...
In general, this improves SMP performance, and in some cases allows the
SMP port to work in places it wouldn't before. Such as the PREEMPT_RT
state where the slab is protected by a per-cpu spin lock. If the slab
kmalloc/kfree were to put the task to sleep, and that task was actually
the IPI handler, then the system falls down yet again.
After running some various stress tests on the system, the static limit
of 5 messages seems to work. On the off chance even this overflows, we
simply panic(), and we can review that scenario to see if the limit needs
to be increased a bit more.
Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2009-12-17 16:20:32 +08:00
|
|
|
platform_request_ipi(IRQ_SUPPLE_0, ipi_handler_int0);
|
|
|
|
platform_request_ipi(IRQ_SUPPLE_1, ipi_handler_int1);
|
2009-01-07 23:14:39 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void __init smp_cpus_done(unsigned int max_cpus)
|
|
|
|
{
|
|
|
|
unsigned long bogosum = 0;
|
|
|
|
unsigned int cpu;
|
|
|
|
|
|
|
|
for_each_online_cpu(cpu)
|
2009-07-09 17:58:52 +08:00
|
|
|
bogosum += loops_per_jiffy;
|
2009-01-07 23:14:39 +08:00
|
|
|
|
|
|
|
printk(KERN_INFO "SMP: Total of %d processors activated "
|
|
|
|
"(%lu.%02lu BogoMIPS).\n",
|
|
|
|
num_online_cpus(),
|
|
|
|
bogosum / (500000/HZ),
|
|
|
|
(bogosum / (5000/HZ)) % 100);
|
|
|
|
}
|
|
|
|
|
|
|
|
void smp_icache_flush_range_others(unsigned long start, unsigned long end)
|
|
|
|
{
|
|
|
|
smp_flush_data.start = start;
|
|
|
|
smp_flush_data.end = end;
|
|
|
|
|
2009-03-05 16:44:53 +08:00
|
|
|
if (smp_call_function(&ipi_flush_icache, &smp_flush_data, 0))
|
2009-01-07 23:14:39 +08:00
|
|
|
printk(KERN_WARNING "SMP: failed to run I-cache flush request on other CPUs\n");
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(smp_icache_flush_range_others);
|
|
|
|
|
2009-06-10 16:57:08 +08:00
|
|
|
#ifdef __ARCH_SYNC_CORE_ICACHE
|
2010-02-01 14:07:50 +08:00
|
|
|
unsigned long icache_invld_count[NR_CPUS];
|
2009-06-10 16:57:08 +08:00
|
|
|
void resync_core_icache(void)
|
|
|
|
{
|
|
|
|
unsigned int cpu = get_cpu();
|
|
|
|
blackfin_invalidate_entire_icache();
|
2010-02-01 14:07:50 +08:00
|
|
|
icache_invld_count[cpu]++;
|
2009-06-10 16:57:08 +08:00
|
|
|
put_cpu();
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(resync_core_icache);
|
|
|
|
#endif
|
|
|
|
|
2009-01-07 23:14:39 +08:00
|
|
|
#ifdef __ARCH_SYNC_CORE_DCACHE
|
2010-02-01 14:07:50 +08:00
|
|
|
unsigned long dcache_invld_count[NR_CPUS];
|
2009-01-07 23:14:39 +08:00
|
|
|
unsigned long barrier_mask __attribute__ ((__section__(".l2.bss")));
|
|
|
|
|
|
|
|
void resync_core_dcache(void)
|
|
|
|
{
|
|
|
|
unsigned int cpu = get_cpu();
|
|
|
|
blackfin_invalidate_entire_dcache();
|
2010-02-01 14:07:50 +08:00
|
|
|
dcache_invld_count[cpu]++;
|
2009-01-07 23:14:39 +08:00
|
|
|
put_cpu();
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(resync_core_dcache);
|
|
|
|
#endif
|
2009-12-28 19:13:51 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_HOTPLUG_CPU
|
|
|
|
int __cpuexit __cpu_disable(void)
|
|
|
|
{
|
|
|
|
unsigned int cpu = smp_processor_id();
|
|
|
|
|
|
|
|
if (cpu == 0)
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
set_cpu_online(cpu, false);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static DECLARE_COMPLETION(cpu_killed);
|
|
|
|
|
|
|
|
int __cpuexit __cpu_die(unsigned int cpu)
|
|
|
|
{
|
|
|
|
return wait_for_completion_timeout(&cpu_killed, 5000);
|
|
|
|
}
|
|
|
|
|
|
|
|
void cpu_die(void)
|
|
|
|
{
|
|
|
|
complete(&cpu_killed);
|
|
|
|
|
|
|
|
atomic_dec(&init_mm.mm_users);
|
|
|
|
atomic_dec(&init_mm.mm_count);
|
|
|
|
|
|
|
|
local_irq_disable();
|
|
|
|
platform_cpu_die();
|
|
|
|
}
|
|
|
|
#endif
|