blackfin architecture
This adds support for the Analog Devices Blackfin processor architecture, and
currently supports the BF533, BF532, BF531, BF537, BF536, BF534, and BF561
(Dual Core) devices, with a variety of development platforms including those
avaliable from Analog Devices (BF533-EZKit, BF533-STAMP, BF537-STAMP,
BF561-EZKIT), and Bluetechnix! Tinyboards.
The Blackfin architecture was jointly developed by Intel and Analog Devices
Inc. (ADI) as the Micro Signal Architecture (MSA) core and introduced it in
December of 2000. Since then ADI has put this core into its Blackfin
processor family of devices. The Blackfin core has the advantages of a clean,
orthogonal,RISC-like microprocessor instruction set. It combines a dual-MAC
(Multiply/Accumulate), state-of-the-art signal processing engine and
single-instruction, multiple-data (SIMD) multimedia capabilities into a single
instruction-set architecture.
The Blackfin architecture, including the instruction set, is described by the
ADSP-BF53x/BF56x Blackfin Processor Programming Reference
http://blackfin.uclinux.org/gf/download/frsrelease/29/2549/Blackfin_PRM.pdf
The Blackfin processor is already supported by major releases of gcc, and
there are binary and source rpms/tarballs for many architectures at:
http://blackfin.uclinux.org/gf/project/toolchain/frs There is complete
documentation, including "getting started" guides available at:
http://docs.blackfin.uclinux.org/ which provides links to the sources and
patches you will need in order to set up a cross-compiling environment for
bfin-linux-uclibc
This patch, as well as the other patches (toolchain, distribution,
uClibc) are actively supported by Analog Devices Inc, at:
http://blackfin.uclinux.org/
We have tested this on LTP, and our test plan (including pass/fails) can
be found at:
http://docs.blackfin.uclinux.org/doku.php?id=testing_the_linux_kernel
[m.kozlowski@tuxland.pl: balance parenthesis in blackfin header files]
Signed-off-by: Bryan Wu <bryan.wu@analog.com>
Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
Signed-off-by: Aubrey Li <aubrey.li@analog.com>
Signed-off-by: Jie Zhang <jie.zhang@analog.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-06 21:50:22 +00:00
|
|
|
/*
|
|
|
|
* Pull in the generic implementation for the mutex fastpath.
|
|
|
|
*
|
|
|
|
* TODO: implement optimized primitives instead, or leave the generic
|
|
|
|
* implementation in place, or pick the atomic_xchg() based generic
|
|
|
|
* implementation. (see asm-generic/mutex-xchg.h for details)
|
|
|
|
*/
|
|
|
|
|
2009-01-07 15:14:39 +00:00
|
|
|
#ifndef _ASM_MUTEX_H
|
|
|
|
#define _ASM_MUTEX_H
|
|
|
|
|
|
|
|
#ifndef CONFIG_SMP
|
2009-06-13 15:21:51 +00:00
|
|
|
#include <asm-generic/mutex.h>
|
2009-01-07 15:14:39 +00:00
|
|
|
#else
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
__mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *))
|
|
|
|
{
|
|
|
|
if (unlikely(atomic_dec_return(count) < 0))
|
|
|
|
fail_fn(count);
|
|
|
|
else
|
|
|
|
smp_mb();
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
__mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *))
|
|
|
|
{
|
|
|
|
if (unlikely(atomic_dec_return(count) < 0))
|
|
|
|
return fail_fn(count);
|
|
|
|
else {
|
|
|
|
smp_mb();
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
__mutex_fastpath_unlock(atomic_t *count, void (*fail_fn)(atomic_t *))
|
|
|
|
{
|
|
|
|
smp_mb();
|
|
|
|
if (unlikely(atomic_inc_return(count) <= 0))
|
|
|
|
fail_fn(count);
|
|
|
|
}
|
|
|
|
|
|
|
|
#define __mutex_slowpath_needs_to_unlock() 1
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
__mutex_fastpath_trylock(atomic_t *count, int (*fail_fn)(atomic_t *))
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We have two variants here. The cmpxchg based one is the best one
|
|
|
|
* because it never induce a false contention state. It is included
|
|
|
|
* here because architectures using the inc/dec algorithms over the
|
|
|
|
* xchg ones are much more likely to support cmpxchg natively.
|
|
|
|
*
|
|
|
|
* If not we fall back to the spinlock based variant - that is
|
|
|
|
* just as efficient (and simpler) as a 'destructive' probing of
|
|
|
|
* the mutex state would be.
|
|
|
|
*/
|
|
|
|
#ifdef __HAVE_ARCH_CMPXCHG
|
|
|
|
if (likely(atomic_cmpxchg(count, 1, 0) == 1)) {
|
|
|
|
smp_mb();
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
#else
|
|
|
|
return fail_fn(count);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#endif
|