|
2 | 2 | #ifndef __PARISC_LDCW_H
|
3 | 3 | #define __PARISC_LDCW_H
|
4 | 4 |
|
5 |
| -#ifndef CONFIG_PA20 |
6 | 5 | /* Because kmalloc only guarantees 8-byte alignment for kmalloc'd data,
|
7 | 6 | and GCC only guarantees 8-byte alignment for stack locals, we can't
|
8 | 7 | be assured of 16-byte alignment for atomic lock data even if we
|
9 | 8 | specify "__attribute ((aligned(16)))" in the type declaration. So,
|
10 | 9 | we use a struct containing an array of four ints for the atomic lock
|
11 | 10 | type and dynamically select the 16-byte aligned int from the array
|
12 |
| - for the semaphore. */ |
| 11 | + for the semaphore. */ |
| 12 | + |
| 13 | +/* From: "Jim Hull" <jim.hull of hp.com> |
| 14 | + I've attached a summary of the change, but basically, for PA 2.0, as |
| 15 | + long as the ",CO" (coherent operation) completer is implemented, then the |
| 16 | + 16-byte alignment requirement for ldcw and ldcd is relaxed, and instead |
| 17 | + they only require "natural" alignment (4-byte for ldcw, 8-byte for |
| 18 | + ldcd). |
| 19 | +
|
| 20 | + Although the cache control hint is accepted by all PA 2.0 processors, |
| 21 | + it is only implemented on PA8800/PA8900 CPUs. Prior PA8X00 CPUs still |
| 22 | + require 16-byte alignment. If the address is unaligned, the operation |
| 23 | + of the instruction is undefined. The ldcw instruction does not generate |
| 24 | + unaligned data reference traps so misaligned accesses are not detected. |
| 25 | + This hid the problem for years. So, restore the 16-byte alignment dropped |
| 26 | + by Kyle McMartin in "Remove __ldcw_align for PA-RISC 2.0 processors". */ |
13 | 27 |
|
14 | 28 | #define __PA_LDCW_ALIGNMENT 16
|
15 |
| -#define __PA_LDCW_ALIGN_ORDER 4 |
16 | 29 | #define __ldcw_align(a) ({ \
|
17 | 30 | unsigned long __ret = (unsigned long) &(a)->lock[0]; \
|
18 | 31 | __ret = (__ret + __PA_LDCW_ALIGNMENT - 1) \
|
19 | 32 | & ~(__PA_LDCW_ALIGNMENT - 1); \
|
20 | 33 | (volatile unsigned int *) __ret; \
|
21 | 34 | })
|
22 |
| -#define __LDCW "ldcw" |
23 | 35 |
|
24 |
| -#else /*CONFIG_PA20*/ |
25 |
| -/* From: "Jim Hull" <jim.hull of hp.com> |
26 |
| - I've attached a summary of the change, but basically, for PA 2.0, as |
27 |
| - long as the ",CO" (coherent operation) completer is specified, then the |
28 |
| - 16-byte alignment requirement for ldcw and ldcd is relaxed, and instead |
29 |
| - they only require "natural" alignment (4-byte for ldcw, 8-byte for |
30 |
| - ldcd). */ |
31 |
| - |
32 |
| -#define __PA_LDCW_ALIGNMENT 4 |
33 |
| -#define __PA_LDCW_ALIGN_ORDER 2 |
34 |
| -#define __ldcw_align(a) (&(a)->slock) |
| 36 | +#ifdef CONFIG_PA20 |
35 | 37 | #define __LDCW "ldcw,co"
|
36 |
| - |
37 |
| -#endif /*!CONFIG_PA20*/ |
| 38 | +#else |
| 39 | +#define __LDCW "ldcw" |
| 40 | +#endif |
38 | 41 |
|
39 | 42 | /* LDCW, the only atomic read-write operation PA-RISC has. *sigh*.
|
40 | 43 | We don't explicitly expose that "*a" may be written as reload
|
|
0 commit comments