blob: e4422b4b634e6b7a0053b84f76bb605664eace52 [file] [log] [blame]
Arnaldo Carvalho de Melo163e5892015-05-07 18:03:14 -03001/*
2 * Copied from the kernel sources to tools/:
3 *
4 * Memory barrier definitions. This is based on information published
5 * in the Processor Abstraction Layer and the System Abstraction Layer
6 * manual.
7 *
8 * Copyright (C) 1998-2003 Hewlett-Packard Co
9 * David Mosberger-Tang <davidm@hpl.hp.com>
10 * Copyright (C) 1999 Asit Mallick <asit.k.mallick@intel.com>
11 * Copyright (C) 1999 Don Dugger <don.dugger@intel.com>
12 */
13#ifndef _TOOLS_LINUX_ASM_IA64_BARRIER_H
14#define _TOOLS_LINUX_ASM_IA64_BARRIER_H
15
16#include <linux/compiler.h>
17
18/*
19 * Macros to force memory ordering. In these descriptions, "previous"
20 * and "subsequent" refer to program order; "visible" means that all
21 * architecturally visible effects of a memory access have occurred
22 * (at a minimum, this means the memory has been read or written).
23 *
24 * wmb(): Guarantees that all preceding stores to memory-
25 * like regions are visible before any subsequent
26 * stores and that all following stores will be
27 * visible only after all previous stores.
28 * rmb(): Like wmb(), but for reads.
29 * mb(): wmb()/rmb() combo, i.e., all previous memory
30 * accesses are visible before all subsequent
31 * accesses and vice versa. This is also known as
32 * a "fence."
33 *
34 * Note: "mb()" and its variants cannot be used as a fence to order
35 * accesses to memory mapped I/O registers. For that, mf.a needs to
36 * be used. However, we don't want to always use mf.a because (a)
37 * it's (presumably) much slower than mf and (b) mf.a is supported for
38 * sequential memory pages only.
39 */
40
41/* XXX From arch/ia64/include/uapi/asm/gcc_intrin.h */
42#define ia64_mf() asm volatile ("mf" ::: "memory")
43
44#define mb() ia64_mf()
45#define rmb() mb()
46#define wmb() mb()
47
48#endif /* _TOOLS_LINUX_ASM_IA64_BARRIER_H */