Linux 3.17-rc2
[linux/fpc-iii.git] / arch / parisc / include / asm / ldcw.h
blobd2d11b7055ba640178817917d04c46364453c069
1 #ifndef __PARISC_LDCW_H
2 #define __PARISC_LDCW_H
4 #ifndef CONFIG_PA20
5 /* Because kmalloc only guarantees 8-byte alignment for kmalloc'd data,
6 and GCC only guarantees 8-byte alignment for stack locals, we can't
7 be assured of 16-byte alignment for atomic lock data even if we
8 specify "__attribute ((aligned(16)))" in the type declaration. So,
9 we use a struct containing an array of four ints for the atomic lock
10 type and dynamically select the 16-byte aligned int from the array
11 for the semaphore. */
13 #define __PA_LDCW_ALIGNMENT 16
14 #define __ldcw_align(a) ({ \
15 unsigned long __ret = (unsigned long) &(a)->lock[0]; \
16 __ret = (__ret + __PA_LDCW_ALIGNMENT - 1) \
17 & ~(__PA_LDCW_ALIGNMENT - 1); \
18 (volatile unsigned int *) __ret; \
20 #define __LDCW "ldcw"
22 #else /*CONFIG_PA20*/
23 /* From: "Jim Hull" <jim.hull of hp.com>
24 I've attached a summary of the change, but basically, for PA 2.0, as
25 long as the ",CO" (coherent operation) completer is specified, then the
26 16-byte alignment requirement for ldcw and ldcd is relaxed, and instead
27 they only require "natural" alignment (4-byte for ldcw, 8-byte for
28 ldcd). */
30 #define __PA_LDCW_ALIGNMENT 4
31 #define __ldcw_align(a) (&(a)->slock)
32 #define __LDCW "ldcw,co"
34 #endif /*!CONFIG_PA20*/
36 /* LDCW, the only atomic read-write operation PA-RISC has. *sigh*. */
37 #define __ldcw(a) ({ \
38 unsigned __ret; \
39 __asm__ __volatile__(__LDCW " 0(%2),%0" \
40 : "=r" (__ret), "+m" (*(a)) : "r" (a)); \
41 __ret; \
44 #ifdef CONFIG_SMP
45 # define __lock_aligned __attribute__((__section__(".data..lock_aligned")))
46 #endif
48 #endif /* __PARISC_LDCW_H */