.. | .. |
---|
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 | 29 | #define __PA_LDCW_ALIGN_ORDER 4 |
---|
.. | .. |
---|
19 | 33 | & ~(__PA_LDCW_ALIGNMENT - 1); \ |
---|
20 | 34 | (volatile unsigned int *) __ret; \ |
---|
21 | 35 | }) |
---|
22 | | -#define __LDCW "ldcw" |
---|
23 | 36 | |
---|
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) |
---|
| 37 | +#ifdef CONFIG_PA20 |
---|
35 | 38 | #define __LDCW "ldcw,co" |
---|
36 | | - |
---|
37 | | -#endif /*!CONFIG_PA20*/ |
---|
| 39 | +#else |
---|
| 40 | +#define __LDCW "ldcw" |
---|
| 41 | +#endif |
---|
38 | 42 | |
---|
39 | 43 | /* LDCW, the only atomic read-write operation PA-RISC has. *sigh*. |
---|
40 | 44 | We don't explicitly expose that "*a" may be written as reload |
---|