Documentation/core-api/bus-virt-phys-mapping.rst

2 How to access I/O mapped memory from within device drivers
11 	(see :doc:`/core-api/dma-api-howto`).  They continue
12 	to be documented below for historical purposes, but new code
13 	must not use them. --davidm 00/12/12
17   [ This is a mail message in response to a query on IO mapping, thus the
20 The AHA-1542 is a bus-master device, and your patch makes the driver give the
22 (because all bus master devices see the physical memory mappings directly).
25 at memory addresses, and in this case we actually want the third, the
26 so-called "bus address".
28 Essentially, the three ways of addressing memory are (this is "real memory",
29 that is, normal RAM--see later about other details):
31  - CPU untranslated.  This is the "physical" address.  Physical address
32    0 is what the CPU sees when it drives zeroes on the memory bus.
34  - CPU translated address. This is the "virtual" address, and is
35    completely internal to the CPU itself with the CPU doing the appropriate
38  - bus address. This is the address of memory as seen by OTHER devices,
40    addresses, with each device seeing memory in some device-specific way, but
41    happily most hardware designers aren't actually actively trying to make
43    external hardware sees the memory the same way.
47 because the memory and the devices share the same address space, and that is
51 CPU sees a memory map something like this (this is from memory)::
53 	0-2 GB		"real memory"
54 	2 GB-3 GB	"system IO" (inb/out and similar accesses on x86)
55 	3 GB-4 GB 	"IO memory" (shared memory over the IO bus)
58 the viewpoint of the devices, you have the reverse, and the physical memory
61 So when the CPU wants any bus master to write to physical memory 0, it
62 has to give the master address 0x80000000 as the memory address.
71 where all the addresses actually point to the same thing.  It's just seen
83 Anyway, the way to look up all these translations, you do::
94 You want the **virtual** address when you are actually going to access that
98 	 * this is the hardware "mailbox" we use to communicate with
117 you want to give to the controller::
119 	/* ask the controller to read the sense status into "sense_buffer" */
125 And you generally **never** want to use the physical address, because you can't
131 address is needed if you use memory mappings, for example, because the
132 "remap_pfn_range()" mm function wants the physical address of the memory to
133 be remapped as measured in units of pages, a.k.a. the pfn (the memory
135 shouldn't need to know about "bus addresses" etc).
140 	only talks about "real memory", that is, CPU memory (RAM).
142 There is a completely different type of memory too, and that's the "shared
143 memory" on the PCI or ISA bus. That's generally not RAM (although in the case
147 This memory is called "PCI memory" or "shared memory" or "IO memory" or
148 whatever, and there is only one way to access it: the readb/writeb and
149 related functions. You should never take the address of such memory, because
151 conceptually in the same memory space as "real memory" at all, so you cannot
152 just dereference a pointer. (Sadly, on x86 it **is** in the same memory space,
153 so on x86 it actually works to just deference a pointer, but it's not
156 For such memory, you can do things like:
158  - reading::
161 	 * read first 32 bits from ISA memory at 0xC0000, aka
166  - remapping and writing::
169 	 * remap framebuffer PCI memory area at 0xFC000000,
171 	 * access only the 640k-1MB area, so anything else
172 	 * has to be remapped.
176 	/* write a 'A' to the offset 10 of the area */
182  - copying and clearing::
184 	/* get the 6-byte Ethernet address at ISA address E000:0040 */
186 	/* write a packet to the driver */
187 	memcpy_toio(0xE1000, skb->data, skb->len);
198 didn't think straight when I wrote it originally.  People who have to
213 It's generally not hard to fix drivers, and in many cases the code