Commit Graph

6 Commits

Author SHA1 Message Date
Andrea Parri
8d235b174a
riscv/barrier: Define __smp_{store_release,load_acquire}
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>
2018-04-02 19:59:43 -07:00
Andrea Parri
ab4af60534
riscv/barrier: Define __smp_{mb,rmb,wmb}
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>
2018-02-26 08:44:50 -08:00
Palmer Dabbelt
3cfa500808
RISC-V: Resurrect smp_mb__after_spinlock()
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: 3343eb6806 ("RISC-V: Remove smb_mb__{before,after}_spinlock()")
CC: Andrea Parri <parri.andrea@gmail.com>
Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2017-12-11 07:51:07 -08:00
Palmer Dabbelt
3343eb6806 RISC-V: Remove smb_mb__{before,after}_spinlock()
These are obselete.

Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2017-11-28 14:03:55 -08:00
Palmer Dabbelt
61a60d35b7 RISC-V: Remove __smp_bp__{before,after}_atomic
These duplicate the asm-generic definitions are therefor aren't useful.

Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2017-11-28 14:03:48 -08:00
Palmer Dabbelt
fab957c11e RISC-V: Atomic and Locking Code
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>
2017-09-26 15:26:45 -07:00