2009-01-07 15:14:39 +00:00
|
|
|
/*
|
2009-09-24 14:11:24 +00:00
|
|
|
* Copyright 2007-2009 Analog Devices Inc.
|
|
|
|
* Philippe Gerum <rpm@xenomai.org>
|
2009-01-07 15:14:39 +00:00
|
|
|
*
|
2009-09-24 14:11:24 +00:00
|
|
|
* Licensed under the GPL-2 or later.
|
2009-01-07 15:14:39 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <asm/smp.h>
|
|
|
|
#include <asm/dma.h>
|
2009-12-28 10:21:49 +00:00
|
|
|
#include <asm/time.h>
|
2009-01-07 15:14:39 +00:00
|
|
|
|
|
|
|
static DEFINE_SPINLOCK(boot_lock);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* platform_init_cpus() - Tell the world about how many cores we
|
|
|
|
* have. This is called while setting up the architecture support
|
|
|
|
* (setup_arch()), so don't be too demanding here with respect to
|
|
|
|
* available kernel services.
|
|
|
|
*/
|
|
|
|
|
|
|
|
void __init platform_init_cpus(void)
|
|
|
|
{
|
|
|
|
cpu_set(0, cpu_possible_map); /* CoreA */
|
|
|
|
cpu_set(1, cpu_possible_map); /* CoreB */
|
|
|
|
}
|
|
|
|
|
|
|
|
void __init platform_prepare_cpus(unsigned int max_cpus)
|
|
|
|
{
|
2010-08-05 07:49:26 +00:00
|
|
|
bfin_relocate_coreb_l1_mem();
|
2009-01-07 15:14:39 +00:00
|
|
|
|
|
|
|
/* Both cores ought to be present on a bf561! */
|
|
|
|
cpu_set(0, cpu_present_map); /* CoreA */
|
|
|
|
cpu_set(1, cpu_present_map); /* CoreB */
|
|
|
|
}
|
|
|
|
|
|
|
|
int __init setup_profiling_timer(unsigned int multiplier) /* not supported */
|
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
void __cpuinit platform_secondary_init(unsigned int cpu)
|
|
|
|
{
|
|
|
|
/* Clone setup for peripheral interrupt sources from CoreA. */
|
2010-10-19 18:44:23 +00:00
|
|
|
bfin_write_SICB_IMASK0(bfin_read_SIC_IMASK0());
|
|
|
|
bfin_write_SICB_IMASK1(bfin_read_SIC_IMASK1());
|
2009-01-07 15:14:39 +00:00
|
|
|
SSYNC();
|
|
|
|
|
|
|
|
/* Clone setup for IARs from CoreA. */
|
2010-10-19 18:44:23 +00:00
|
|
|
bfin_write_SICB_IAR0(bfin_read_SIC_IAR0());
|
|
|
|
bfin_write_SICB_IAR1(bfin_read_SIC_IAR1());
|
|
|
|
bfin_write_SICB_IAR2(bfin_read_SIC_IAR2());
|
|
|
|
bfin_write_SICB_IAR3(bfin_read_SIC_IAR3());
|
|
|
|
bfin_write_SICB_IAR4(bfin_read_SIC_IAR4());
|
|
|
|
bfin_write_SICB_IAR5(bfin_read_SIC_IAR5());
|
|
|
|
bfin_write_SICB_IAR6(bfin_read_SIC_IAR6());
|
|
|
|
bfin_write_SICB_IAR7(bfin_read_SIC_IAR7());
|
2009-12-28 11:13:51 +00:00
|
|
|
bfin_write_SICB_IWR0(IWR_DISABLE_ALL);
|
|
|
|
bfin_write_SICB_IWR1(IWR_DISABLE_ALL);
|
2009-01-07 15:14:39 +00:00
|
|
|
SSYNC();
|
|
|
|
|
|
|
|
/* We are done with local CPU inits, unblock the boot CPU. */
|
2009-12-28 09:27:27 +00:00
|
|
|
set_cpu_online(cpu, true);
|
2009-01-07 15:14:39 +00:00
|
|
|
spin_lock(&boot_lock);
|
|
|
|
spin_unlock(&boot_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
int __cpuinit platform_boot_secondary(unsigned int cpu, struct task_struct *idle)
|
|
|
|
{
|
|
|
|
unsigned long timeout;
|
|
|
|
|
|
|
|
printk(KERN_INFO "Booting Core B.\n");
|
|
|
|
|
|
|
|
spin_lock(&boot_lock);
|
|
|
|
|
2010-10-27 14:06:32 +00:00
|
|
|
if ((bfin_read_SYSCR() & COREB_SRAM_INIT) == 0) {
|
2009-12-28 11:13:51 +00:00
|
|
|
/* CoreB already running, sending ipi to wakeup it */
|
|
|
|
platform_send_ipi_cpu(cpu, IRQ_SUPPLE_0);
|
|
|
|
} else {
|
|
|
|
/* Kick CoreB, which should start execution from CORE_SRAM_BASE. */
|
2010-10-27 14:06:32 +00:00
|
|
|
bfin_write_SYSCR(bfin_read_SYSCR() & ~COREB_SRAM_INIT);
|
2009-12-28 11:13:51 +00:00
|
|
|
SSYNC();
|
|
|
|
}
|
2009-01-07 15:14:39 +00:00
|
|
|
|
|
|
|
timeout = jiffies + 1 * HZ;
|
|
|
|
while (time_before(jiffies, timeout)) {
|
2009-12-28 09:27:27 +00:00
|
|
|
if (cpu_online(cpu))
|
2009-01-07 15:14:39 +00:00
|
|
|
break;
|
|
|
|
udelay(100);
|
|
|
|
barrier();
|
|
|
|
}
|
|
|
|
|
2009-12-28 09:27:27 +00:00
|
|
|
if (cpu_online(cpu)) {
|
2009-12-02 07:58:12 +00:00
|
|
|
/* release the lock and let coreb run */
|
|
|
|
spin_unlock(&boot_lock);
|
|
|
|
return 0;
|
|
|
|
} else
|
|
|
|
panic("CPU%u: processor failed to boot\n", cpu);
|
2009-01-07 15:14:39 +00: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 08:20:32 +00:00
|
|
|
static const char supple0[] = "IRQ_SUPPLE_0";
|
|
|
|
static const char supple1[] = "IRQ_SUPPLE_1";
|
|
|
|
void __init platform_request_ipi(int irq, void *handler)
|
2009-01-07 15:14:39 +00:00
|
|
|
{
|
|
|
|
int ret;
|
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 08:20:32 +00:00
|
|
|
const char *name = (irq == IRQ_SUPPLE_0) ? supple0 : supple1;
|
2009-01-07 15:14:39 +00: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 08:20:32 +00:00
|
|
|
ret = request_irq(irq, handler, IRQF_DISABLED | IRQF_PERCPU, name, handler);
|
2009-01-07 15:14:39 +00:00
|
|
|
if (ret)
|
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 08:20:32 +00:00
|
|
|
panic("Cannot request %s for IPI service", name);
|
2009-01-07 15:14:39 +00: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 08:20:32 +00:00
|
|
|
void platform_send_ipi(cpumask_t callmap, int irq)
|
2009-01-07 15:14:39 +00:00
|
|
|
{
|
|
|
|
unsigned 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 08:20:32 +00:00
|
|
|
int offset = (irq == IRQ_SUPPLE_0) ? 6 : 8;
|
2009-01-07 15:14:39 +00:00
|
|
|
|
|
|
|
for_each_cpu_mask(cpu, callmap) {
|
|
|
|
BUG_ON(cpu >= 2);
|
|
|
|
SSYNC();
|
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 08:20:32 +00:00
|
|
|
bfin_write_SICB_SYSCR(bfin_read_SICB_SYSCR() | (1 << (offset + cpu)));
|
2009-01-07 15:14:39 +00:00
|
|
|
SSYNC();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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 08:20:32 +00:00
|
|
|
void platform_send_ipi_cpu(unsigned int cpu, int irq)
|
2009-01-07 15:14:39 +00: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 08:20:32 +00:00
|
|
|
int offset = (irq == IRQ_SUPPLE_0) ? 6 : 8;
|
2009-01-07 15:14:39 +00:00
|
|
|
BUG_ON(cpu >= 2);
|
|
|
|
SSYNC();
|
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 08:20:32 +00:00
|
|
|
bfin_write_SICB_SYSCR(bfin_read_SICB_SYSCR() | (1 << (offset + cpu)));
|
2009-01-07 15:14:39 +00:00
|
|
|
SSYNC();
|
|
|
|
}
|
|
|
|
|
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 08:20:32 +00:00
|
|
|
void platform_clear_ipi(unsigned int cpu, int irq)
|
2009-01-07 15:14:39 +00: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 08:20:32 +00:00
|
|
|
int offset = (irq == IRQ_SUPPLE_0) ? 10 : 12;
|
2009-01-07 15:14:39 +00:00
|
|
|
BUG_ON(cpu >= 2);
|
|
|
|
SSYNC();
|
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 08:20:32 +00:00
|
|
|
bfin_write_SICB_SYSCR(bfin_read_SICB_SYSCR() | (1 << (offset + cpu)));
|
2009-01-07 15:14:39 +00:00
|
|
|
SSYNC();
|
|
|
|
}
|
2009-12-28 10:21:49 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Setup core B's local core timer.
|
|
|
|
* In SMP, core timer is used for clock event device.
|
|
|
|
*/
|
|
|
|
void __cpuinit bfin_local_timer_setup(void)
|
|
|
|
{
|
|
|
|
#if defined(CONFIG_TICKSOURCE_CORETMR)
|
2011-03-24 16:21:01 +00:00
|
|
|
struct irq_data *data = irq_get_irq_data(IRQ_CORETMR);
|
|
|
|
struct irq_chip *chip = irq_data_get_irq_chip(data);
|
2011-03-18 07:03:23 +00:00
|
|
|
|
2009-12-28 10:21:49 +00:00
|
|
|
bfin_coretmr_init();
|
|
|
|
bfin_coretmr_clockevent_init();
|
2011-03-18 07:03:23 +00:00
|
|
|
|
2011-03-24 16:21:01 +00:00
|
|
|
chip->irq_unmask(data);
|
2009-12-28 10:21:49 +00:00
|
|
|
#else
|
|
|
|
/* Power down the core timer, just to play safe. */
|
|
|
|
bfin_write_TCNTL(0);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
}
|