| @@ -2,39 +2,42 @@ · 1 unmodified line |
| 2 | #ifndef __PARISC_LDCW_H | 2 | #ifndef __PARISC_LDCW_H |
| 3 | #define __PARISC_LDCW_H | 3 | #define __PARISC_LDCW_H |
| 4 | | 4 | |
| 5 | #ifndef CONFIG_PA20 | | |
| 6 | /* Because kmalloc only guarantees 8-byte alignment for kmalloc'd data, | 5 | /* Because kmalloc only guarantees 8-byte alignment for kmalloc'd data, |
| 7 | and GCC only guarantees 8-byte alignment for stack locals, we can't | 6 | and GCC only guarantees 8-byte alignment for stack locals, we can't |
| 8 | be assured of 16-byte alignment for atomic lock data even if we | 7 | be assured of 16-byte alignment for atomic lock data even if we |
| 9 | specify "__attribute ((aligned(16)))" in the type declaration. So, | 8 | specify "__attribute ((aligned(16)))" in the type declaration. So, |
| 10 | we use a struct containing an array of four ints for the atomic lock | 9 | we use a struct containing an array of four ints for the atomic lock |
| 11 | type and dynamically select the 16-byte aligned int from the array | 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 | #define __PA_LDCW_ALIGNMENT 16 | 28 | #define __PA_LDCW_ALIGNMENT 16 |
| 15 | #define __PA_LDCW_ALIGN_ORDER 4 | | |
| 16 | #define __ldcw_align(a) ({ \ | 29 | #define __ldcw_align(a) ({ \ |
| 17 | unsigned long __ret = (unsigned long) &(a)->lock[0]; \ | 30 | unsigned long __ret = (unsigned long) &(a)->lock[0]; \ |
| 18 | __ret = (__ret + __PA_LDCW_ALIGNMENT - 1) \ | 31 | __ret = (__ret + __PA_LDCW_ALIGNMENT - 1) \ |
| 19 | & ~(__PA_LDCW_ALIGNMENT - 1); \ | 32 | & ~(__PA_LDCW_ALIGNMENT - 1); \ |
| 20 | (volatile unsigned int *) __ret; \ | 33 | (volatile unsigned int *) __ret; \ |
| 21 | }) | 34 | }) |
| 22 | #define __LDCW "ldcw" | | |
| 23 | | 35 | |
| 24 | #else /*CONFIG_PA20*/ | 36 | #ifdef 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) | | |
| 35 | #define __LDCW "ldcw,co" | 37 | #define __LDCW "ldcw,co" |
| 36 | | 38 | #else |
| 37 | #endif /*!CONFIG_PA20*/ | 39 | #define __LDCW "ldcw" |
| | 40 | #endif |
| 38 | | 41 | |
| 39 | /* LDCW, the only atomic read-write operation PA-RISC has. *sigh*. | 42 | /* LDCW, the only atomic read-write operation PA-RISC has. *sigh*. |
| 40 | We don't explicitly expose that "*a" may be written as reload | 43 | We don't explicitly expose that "*a" may be written as reload |