Use the trigger type in irq_data and check level type instead of
looking at desc->handle_irq.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: uclinux-dist-devel@blackfin.uclinux.org

Signed-off-by: NMike Frysinger <vapier@gentoo.org>

In order to safely work around anomaly 05000491, we have to execute IFLUSH
from L1 instruction sram.  The trouble with multi-core systems is that all
L1 sram is visible only to the active core.  So we can't just place the
functions into L1 and call it directly.  We need to setup a jump table and
place the entry point in external memory.  This will call the right func
based on the active core.

In the process, convert from the manual relocation of a small bit of code
into Core B's L1 to the more general framework we already have in place
for loading arbitrary pieces of code into L1.
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

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: NYi Li <yi.li@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

This function takes an irq_handler_t function, but the prototype in
the header doesn't match the function definition.  This is due to the
smp headers needing to avoid circular dependencies.  So change the
function to take a simple pointer.
Signed-off-by: NGraf Yang <graf.yang@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Looks like I missed a few new spots when renaming the SICA macros.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

This matches all the other Blackfin ports and keep us from having to write
bf561-specific code in many places.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Signed-off-by: NGraf Yang <graf.yang@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

SMP systems require per-cpu local clock event devices in order to enable
HRT support.  One a BF561, we can use local core timer for this purpose.
Originally, there was one global core-timer clock event device set up for
core A.

To accomplish this feat, we need to split the gptimer0/core timer logic
so that each is a standalone clock event.  There is no requirement that
we only have one clock event source anyways.  Once we have this, we just
define per-cpu clock event devices for each local core timer.
Signed-off-by: NYi Li <yi.li@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Common API already provides functions for managing online CPUs.
Signed-off-by: NGraf Yang <graf.yang@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

When testing PREEMPT_RT kernel on BF561-EZKit, the kernel blocks while
booting.  When the kernel initializes the ethernet driver, it sleeps and
never wakes up.

The issue happens when the kernel waits for a timer for Core B to timeout
(the timers are per-cpu based: static DEFINE_PER_CPU(struct tvec_base *,
tvec_bases) = &boot_tvec_bases).

However, the ksoftirqd thread for Core B (note, the ksoftirqd thread is
also per-cpu based) cannot work properly, and the timers for Core B never
times out.

When ksoftirqd() for the first time runs on core B, it is possible core A
is still initializing core B (see smp_init() -> cpu_up() -> __cpu_up()).
So the "cpu_is_offline()" check may return true and ksoftirqd moves to
"wait_to_die".

So delay the core b start up until the per-cpu timers have been set up
fully.
Signed-off-by: NYi Li <yi.li@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Bill Gatliff & David Brownell pointed out we were missing some
copyrights, and licensing terms in some of the files in
./arch/blackfin, so this fixes things, and cleans them up.

It also removes:
 - verbose GPL text(refer to the top level ./COPYING file)
 - file names (you are looking at the file)
 - bug url (it's in the ./MAINTAINERS file)
 - "or later" on GPL-2, when we did not have that right

It also allows some Blackfin-specific assembly files to be under a BSD
like license (for people to use them outside of Linux).
Signed-off-by: NRobin Getz <robin.getz@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

For systems where the core cycles are not a usable tick source (like SMP
or cycles gets updated), enable gptimer0 as an alternative.
Signed-off-by: NGraf Yang <graf.yang@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

The panic() function already handles newlines for us.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

1. Use inline get_l1_... functions instead of macro
2. Fix compile issue about smp barrier functions
Signed-off-by: NGraf Yang <graf.yang@analog.com>
Signed-off-by: NBryan Wu <cooloney@kernel.org>

Blackfin dual core BF561 processor can support SMP like features.
https://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:smp-like

In this patch, we provide SMP extend to BF561 kernel code
Signed-off-by: NGraf Yang <graf.yang@analog.com>
Signed-off-by: NMike Frysinger <vapier.adi@gmail.com>
Signed-off-by: NBryan Wu <cooloney@kernel.org>