aboutsummaryrefslogtreecommitdiffstats
path: root/arch/riscv/include/asm/barrier.h
Commit message (Collapse)AuthorAgeFilesLines
* riscv/barrier: Define __smp_{store_release,load_acquire}Andrea Parri2018-04-021-0/+15
| | | | | | | | | Introduce __smp_{store_release,load_acquire}, and rely on the generic definitions for smp_{store_release,load_acquire}. This avoids the use of full ("rw,rw") fences on SMP. Signed-off-by: Andrea Parri <parri.andrea@gmail.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
* riscv/barrier: Define __smp_{mb,rmb,wmb}Andrea Parri2018-02-261-3/+3
| | | | | | | | | | | Introduce __smp_{mb,rmb,wmb}, and rely on the generic definitions for smp_{mb,rmb,wmb}. A first consequence is that smp_{mb,rmb,wmb} map to a compiler barrier on !SMP (while their definition remains unchanged on SMP). As a further consequence, smp_load_acquire and smp_store_release have "fence rw,rw" instead of "fence iorw,iorw". Signed-off-by: Andrea Parri <parri.andrea@gmail.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
* RISC-V: Resurrect smp_mb__after_spinlock()Palmer Dabbelt2017-12-111-0/+19
| | | | | | | | | | | I removed this last week because of an incorrect comment: smp_mb__after_spinlock() is actually still used, and is necessary on RISC-V. It's been resurrected, with a comment that describes what it actually does this time. Thanks to Andrea for finding the bug! Fixes: 3343eb6806f3 ("RISC-V: Remove smb_mb__{before,after}_spinlock()") CC: Andrea Parri <parri.andrea@gmail.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
* RISC-V: Remove smb_mb__{before,after}_spinlock()Palmer Dabbelt2017-11-281-8/+0
| | | | | | These are obselete. Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
* RISC-V: Remove __smp_bp__{before,after}_atomicPalmer Dabbelt2017-11-281-15/+0
| | | | | | These duplicate the asm-generic definitions are therefor aren't useful. Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
* RISC-V: Atomic and Locking CodePalmer Dabbelt2017-09-261-0/+68
This contains all the code that directly interfaces with the RISC-V memory model. While this code corforms to the current RISC-V ISA specifications (user 2.2 and priv 1.10), the memory model is somewhat underspecified in those documents. There is a working group that hopes to produce a formal memory model by the end of the year, but my understanding is that the basic definitions we're relying on here won't change significantly. Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>