Benjamin Herrenschmidt writes:
1- io_to_io_barrier() : This barrier provides ordering requirement #1
between two MMIO accesses. It's to be used in conjuction with fully
relaxed accessors of Class 3.
2- memory_to_io_wb() : This barrier provides ordering requirement #2
between a memory store and an MMIO store. It can be used in conjunction
with write accessors of Class 2 and 3.
3- io_to_memory_rb(value) : This barrier provides ordering requirement
#3 between an MMIO read and a subsequent read from memory. For
implementation purposes on some architectures, the value actually read
by the MMIO read shall be passed as an argument to this barrier. (This
allows to generate the appropriate CPU instruction magic to force the
CPU to consider the value as being "used" and thus force the read to be
performed immediately). It can be used in conjunction with read
accessors of Class 2 and 3
4- io_to_lock_wb() : This barrier provides ordering requirement #4
between an MMIO store and a subsequent spin_unlock(). It can be used in
conjunction with write accessors of Class 2 and 3.
These can really multiply: read or write, RAM and various types
of IO space, etc.
Let's have a generic arch-provided macro and let gcc do some work
for us.
Example usage:
fence(FENCE_READ_RAM|FENCE_READ_PCI_IO, FENCE_WRITE_PCI_MMIO);
Example implementation for PowerPC:
#define PPC_RAM (FENCE_READ_RAM|FENCE_WRITE_RAM)
#define PPC_MMIO (FENCE_READ_PCI_MMIO|FENCE_READ_PCI_CONFIG|\
FENCE_READ_PCI_RAM|FENCE_READ_PCI_IO | FENCE_WRITE_PCI_MMIO|\
FENCE_WRITE_PCI_CONFIG|FENCE_WRITE_PCI_RAM|FENCE_WRITE_PCI_IO)
#define PPC_OTHER (~(PPC_RAM|PPC_MMIO))
#define fence(before,after) do{ \
if(before&PPC_RAM && after&PPC_MMIO) \
__asm__ __volatile__ ("sync" : : : "memory"); \
else if(before&PPC_MMIO && after&PPC_RAM) \
__asm__ __volatile__ ("sync" : : : "memory"); \
else if((before|after) & PPC_OTHER) \
__asm__ __volatile__ ("sync" : : : "memory"); \
else if(before && after) \
__asm__ __volatile__ ("eieio" : : : "memory"); \
}while(0)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
