2010-02-12 05:56:07 +08:00
|
|
|
/*
|
|
|
|
* linux/arch/arm/mach-vexpress/platsmp.c
|
|
|
|
*
|
|
|
|
* Copyright (C) 2002 ARM Ltd.
|
|
|
|
* All Rights Reserved
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*/
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/device.h>
|
|
|
|
#include <linux/jiffies.h>
|
|
|
|
#include <linux/smp.h>
|
|
|
|
#include <linux/io.h>
|
|
|
|
|
|
|
|
#include <asm/cacheflush.h>
|
|
|
|
#include <asm/smp_scu.h>
|
|
|
|
#include <asm/unified.h>
|
|
|
|
|
|
|
|
#include <mach/ct-ca9x4.h>
|
|
|
|
#include <mach/motherboard.h>
|
|
|
|
#define V2M_PA_CS7 0x10000000
|
|
|
|
|
|
|
|
#include "core.h"
|
|
|
|
|
|
|
|
extern void vexpress_secondary_startup(void);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* control for which core is the next to come out of the secondary
|
|
|
|
* boot "holding pen"
|
|
|
|
*/
|
|
|
|
volatile int __cpuinitdata pen_release = -1;
|
|
|
|
|
ARM: Fix subtle race in CPU pen_release hotplug code
There is a subtle race in the CPU hotplug code, where a CPU which has
been offlined can online itself before being requested, which results
in things going astray on the next online/offline cycle.
What happens in the normal online/offline/online cycle is:
CPU0 CPU3
requests boot of CPU3
pen_release = 3
flush cache line
checks pen_release, reads 3
starts boot
pen_release = -1
... requests CPU3 offline ...
... dies ...
checks pen_release, reads -1
requests boot of CPU3
pen_release = 3
flush cache line
checks pen_release, reads 3
starts boot
pen_release = -1
However, as the write of -1 of pen_release is not fully flushed back to
memory, and the checking of pen_release is done with caches disabled,
this allows CPU3 the opportunity to read the old value of pen_release:
CPU0 CPU3
requests boot of CPU3
pen_release = 3
flush cache line
checks pen_release, reads 3
starts boot
pen_release = -1
... requests CPU3 offline ...
... dies ...
checks pen_release, reads 3
starts boot
pen_release = -1
requests boot of CPU3
pen_release = 3
flush cache line
Fix this by grouping the write of pen_release along with its cache line
flushing code to ensure that any update to pen_release is always pushed
out to physical memory.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-12-18 18:53:12 +08:00
|
|
|
/*
|
|
|
|
* Write pen_release in a way that is guaranteed to be visible to all
|
|
|
|
* observers, irrespective of whether they're taking part in coherency
|
|
|
|
* or not. This is necessary for the hotplug code to work reliably.
|
|
|
|
*/
|
2011-01-23 01:22:34 +08:00
|
|
|
static void __cpuinit write_pen_release(int val)
|
ARM: Fix subtle race in CPU pen_release hotplug code
There is a subtle race in the CPU hotplug code, where a CPU which has
been offlined can online itself before being requested, which results
in things going astray on the next online/offline cycle.
What happens in the normal online/offline/online cycle is:
CPU0 CPU3
requests boot of CPU3
pen_release = 3
flush cache line
checks pen_release, reads 3
starts boot
pen_release = -1
... requests CPU3 offline ...
... dies ...
checks pen_release, reads -1
requests boot of CPU3
pen_release = 3
flush cache line
checks pen_release, reads 3
starts boot
pen_release = -1
However, as the write of -1 of pen_release is not fully flushed back to
memory, and the checking of pen_release is done with caches disabled,
this allows CPU3 the opportunity to read the old value of pen_release:
CPU0 CPU3
requests boot of CPU3
pen_release = 3
flush cache line
checks pen_release, reads 3
starts boot
pen_release = -1
... requests CPU3 offline ...
... dies ...
checks pen_release, reads 3
starts boot
pen_release = -1
requests boot of CPU3
pen_release = 3
flush cache line
Fix this by grouping the write of pen_release along with its cache line
flushing code to ensure that any update to pen_release is always pushed
out to physical memory.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-12-18 18:53:12 +08:00
|
|
|
{
|
|
|
|
pen_release = val;
|
|
|
|
smp_wmb();
|
|
|
|
__cpuc_flush_dcache_area((void *)&pen_release, sizeof(pen_release));
|
|
|
|
outer_clean_range(__pa(&pen_release), __pa(&pen_release + 1));
|
|
|
|
}
|
|
|
|
|
2010-02-12 05:56:07 +08:00
|
|
|
static void __iomem *scu_base_addr(void)
|
|
|
|
{
|
|
|
|
return MMIO_P2V(A9_MPCORE_SCU);
|
|
|
|
}
|
|
|
|
|
|
|
|
static DEFINE_SPINLOCK(boot_lock);
|
|
|
|
|
|
|
|
void __cpuinit platform_secondary_init(unsigned int cpu)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* if any interrupts are already enabled for the primary
|
|
|
|
* core (e.g. timer irq), then they will not have been enabled
|
|
|
|
* for us: do so
|
|
|
|
*/
|
2010-12-05 00:01:03 +08:00
|
|
|
gic_secondary_init(0);
|
2010-02-12 05:56:07 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* let the primary processor know we're out of the
|
|
|
|
* pen, then head off into the C entry point
|
|
|
|
*/
|
ARM: Fix subtle race in CPU pen_release hotplug code
There is a subtle race in the CPU hotplug code, where a CPU which has
been offlined can online itself before being requested, which results
in things going astray on the next online/offline cycle.
What happens in the normal online/offline/online cycle is:
CPU0 CPU3
requests boot of CPU3
pen_release = 3
flush cache line
checks pen_release, reads 3
starts boot
pen_release = -1
... requests CPU3 offline ...
... dies ...
checks pen_release, reads -1
requests boot of CPU3
pen_release = 3
flush cache line
checks pen_release, reads 3
starts boot
pen_release = -1
However, as the write of -1 of pen_release is not fully flushed back to
memory, and the checking of pen_release is done with caches disabled,
this allows CPU3 the opportunity to read the old value of pen_release:
CPU0 CPU3
requests boot of CPU3
pen_release = 3
flush cache line
checks pen_release, reads 3
starts boot
pen_release = -1
... requests CPU3 offline ...
... dies ...
checks pen_release, reads 3
starts boot
pen_release = -1
requests boot of CPU3
pen_release = 3
flush cache line
Fix this by grouping the write of pen_release along with its cache line
flushing code to ensure that any update to pen_release is always pushed
out to physical memory.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-12-18 18:53:12 +08:00
|
|
|
write_pen_release(-1);
|
2010-02-12 05:56:07 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Synchronise with the boot thread.
|
|
|
|
*/
|
|
|
|
spin_lock(&boot_lock);
|
|
|
|
spin_unlock(&boot_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
|
|
|
|
{
|
|
|
|
unsigned long timeout;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set synchronisation state between this boot processor
|
|
|
|
* and the secondary one
|
|
|
|
*/
|
|
|
|
spin_lock(&boot_lock);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is really belt and braces; we hold unintended secondary
|
|
|
|
* CPUs in the holding pen until we're ready for them. However,
|
|
|
|
* since we haven't sent them a soft interrupt, they shouldn't
|
|
|
|
* be there.
|
|
|
|
*/
|
ARM: Fix subtle race in CPU pen_release hotplug code
There is a subtle race in the CPU hotplug code, where a CPU which has
been offlined can online itself before being requested, which results
in things going astray on the next online/offline cycle.
What happens in the normal online/offline/online cycle is:
CPU0 CPU3
requests boot of CPU3
pen_release = 3
flush cache line
checks pen_release, reads 3
starts boot
pen_release = -1
... requests CPU3 offline ...
... dies ...
checks pen_release, reads -1
requests boot of CPU3
pen_release = 3
flush cache line
checks pen_release, reads 3
starts boot
pen_release = -1
However, as the write of -1 of pen_release is not fully flushed back to
memory, and the checking of pen_release is done with caches disabled,
this allows CPU3 the opportunity to read the old value of pen_release:
CPU0 CPU3
requests boot of CPU3
pen_release = 3
flush cache line
checks pen_release, reads 3
starts boot
pen_release = -1
... requests CPU3 offline ...
... dies ...
checks pen_release, reads 3
starts boot
pen_release = -1
requests boot of CPU3
pen_release = 3
flush cache line
Fix this by grouping the write of pen_release along with its cache line
flushing code to ensure that any update to pen_release is always pushed
out to physical memory.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-12-18 18:53:12 +08:00
|
|
|
write_pen_release(cpu);
|
2010-02-12 05:56:07 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Send the secondary CPU a soft interrupt, thereby causing
|
|
|
|
* the boot monitor to read the system wide flags register,
|
|
|
|
* and branch to the address found there.
|
|
|
|
*/
|
2010-11-15 17:42:08 +08:00
|
|
|
smp_cross_call(cpumask_of(cpu), 1);
|
2010-02-12 05:56:07 +08:00
|
|
|
|
|
|
|
timeout = jiffies + (1 * HZ);
|
|
|
|
while (time_before(jiffies, timeout)) {
|
|
|
|
smp_rmb();
|
|
|
|
if (pen_release == -1)
|
|
|
|
break;
|
|
|
|
|
|
|
|
udelay(10);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* now the secondary core is starting up let it run its
|
|
|
|
* calibrations, then wait for it to finish
|
|
|
|
*/
|
|
|
|
spin_unlock(&boot_lock);
|
|
|
|
|
|
|
|
return pen_release != -1 ? -ENOSYS : 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialise the CPU possible map early - this describes the CPUs
|
|
|
|
* which may be present or become present in the system.
|
|
|
|
*/
|
|
|
|
void __init smp_init_cpus(void)
|
|
|
|
{
|
|
|
|
void __iomem *scu_base = scu_base_addr();
|
|
|
|
unsigned int i, ncores;
|
|
|
|
|
|
|
|
ncores = scu_base ? scu_get_core_count(scu_base) : 1;
|
|
|
|
|
|
|
|
/* sanity check */
|
|
|
|
if (ncores > NR_CPUS) {
|
|
|
|
printk(KERN_WARNING
|
|
|
|
"vexpress: no. of cores (%d) greater than configured "
|
|
|
|
"maximum of %d - clipping\n",
|
|
|
|
ncores, NR_CPUS);
|
|
|
|
ncores = NR_CPUS;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < ncores; i++)
|
|
|
|
set_cpu_possible(i, true);
|
|
|
|
}
|
|
|
|
|
2010-12-03 19:09:48 +08:00
|
|
|
void __init platform_smp_prepare_cpus(unsigned int max_cpus)
|
2010-02-12 05:56:07 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialise the present map, which describes the set of CPUs
|
|
|
|
* actually populated at the present time.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < max_cpus; i++)
|
|
|
|
set_cpu_present(i, true);
|
|
|
|
|
2010-12-03 19:09:48 +08:00
|
|
|
scu_enable(scu_base_addr());
|
|
|
|
|
2010-02-12 05:56:07 +08:00
|
|
|
/*
|
2010-12-03 19:09:48 +08:00
|
|
|
* Write the address of secondary startup into the
|
|
|
|
* system-wide flags register. The boot monitor waits
|
|
|
|
* until it receives a soft interrupt, and then the
|
|
|
|
* secondary CPU branches to this address.
|
2010-02-12 05:56:07 +08:00
|
|
|
*/
|
2010-12-03 19:09:48 +08:00
|
|
|
writel(~0, MMIO_P2V(V2M_SYS_FLAGSCLR));
|
|
|
|
writel(BSYM(virt_to_phys(vexpress_secondary_startup)),
|
|
|
|
MMIO_P2V(V2M_SYS_FLAGSSET));
|
2010-02-12 05:56:07 +08:00
|
|
|
}
|