Contents of /alx-src/tags/kernel26-2.6.12-alx-r9/Documentation/IO-mapping.txt
Parent Directory | Revision Log
Revision 630 -
(show annotations)
(download)
Wed Mar 4 11:03:09 2009 UTC (15 years, 6 months ago) by niro
File MIME type: text/plain
File size: 8034 byte(s)
Wed Mar 4 11:03:09 2009 UTC (15 years, 6 months ago) by niro
File MIME type: text/plain
File size: 8034 byte(s)
Tag kernel26-2.6.12-alx-r9
1 | [ NOTE: The virt_to_bus() and bus_to_virt() functions have been |
2 | superseded by the functionality provided by the PCI DMA |
3 | interface (see Documentation/DMA-mapping.txt). They continue |
4 | to be documented below for historical purposes, but new code |
5 | must not use them. --davidm 00/12/12 ] |
6 | |
7 | [ This is a mail message in response to a query on IO mapping, thus the |
8 | strange format for a "document" ] |
9 | |
10 | The AHA-1542 is a bus-master device, and your patch makes the driver give the |
11 | controller the physical address of the buffers, which is correct on x86 |
12 | (because all bus master devices see the physical memory mappings directly). |
13 | |
14 | However, on many setups, there are actually _three_ different ways of looking |
15 | at memory addresses, and in this case we actually want the third, the |
16 | so-called "bus address". |
17 | |
18 | Essentially, the three ways of addressing memory are (this is "real memory", |
19 | that is, normal RAM--see later about other details): |
20 | |
21 | - CPU untranslated. This is the "physical" address. Physical address |
22 | 0 is what the CPU sees when it drives zeroes on the memory bus. |
23 | |
24 | - CPU translated address. This is the "virtual" address, and is |
25 | completely internal to the CPU itself with the CPU doing the appropriate |
26 | translations into "CPU untranslated". |
27 | |
28 | - bus address. This is the address of memory as seen by OTHER devices, |
29 | not the CPU. Now, in theory there could be many different bus |
30 | addresses, with each device seeing memory in some device-specific way, but |
31 | happily most hardware designers aren't actually actively trying to make |
32 | things any more complex than necessary, so you can assume that all |
33 | external hardware sees the memory the same way. |
34 | |
35 | Now, on normal PCs the bus address is exactly the same as the physical |
36 | address, and things are very simple indeed. However, they are that simple |
37 | because the memory and the devices share the same address space, and that is |
38 | not generally necessarily true on other PCI/ISA setups. |
39 | |
40 | Now, just as an example, on the PReP (PowerPC Reference Platform), the |
41 | CPU sees a memory map something like this (this is from memory): |
42 | |
43 | 0-2 GB "real memory" |
44 | 2 GB-3 GB "system IO" (inb/out and similar accesses on x86) |
45 | 3 GB-4 GB "IO memory" (shared memory over the IO bus) |
46 | |
47 | Now, that looks simple enough. However, when you look at the same thing from |
48 | the viewpoint of the devices, you have the reverse, and the physical memory |
49 | address 0 actually shows up as address 2 GB for any IO master. |
50 | |
51 | So when the CPU wants any bus master to write to physical memory 0, it |
52 | has to give the master address 0x80000000 as the memory address. |
53 | |
54 | So, for example, depending on how the kernel is actually mapped on the |
55 | PPC, you can end up with a setup like this: |
56 | |
57 | physical address: 0 |
58 | virtual address: 0xC0000000 |
59 | bus address: 0x80000000 |
60 | |
61 | where all the addresses actually point to the same thing. It's just seen |
62 | through different translations.. |
63 | |
64 | Similarly, on the Alpha, the normal translation is |
65 | |
66 | physical address: 0 |
67 | virtual address: 0xfffffc0000000000 |
68 | bus address: 0x40000000 |
69 | |
70 | (but there are also Alphas where the physical address and the bus address |
71 | are the same). |
72 | |
73 | Anyway, the way to look up all these translations, you do |
74 | |
75 | #include <asm/io.h> |
76 | |
77 | phys_addr = virt_to_phys(virt_addr); |
78 | virt_addr = phys_to_virt(phys_addr); |
79 | bus_addr = virt_to_bus(virt_addr); |
80 | virt_addr = bus_to_virt(bus_addr); |
81 | |
82 | Now, when do you need these? |
83 | |
84 | You want the _virtual_ address when you are actually going to access that |
85 | pointer from the kernel. So you can have something like this: |
86 | |
87 | /* |
88 | * this is the hardware "mailbox" we use to communicate with |
89 | * the controller. The controller sees this directly. |
90 | */ |
91 | struct mailbox { |
92 | __u32 status; |
93 | __u32 bufstart; |
94 | __u32 buflen; |
95 | .. |
96 | } mbox; |
97 | |
98 | unsigned char * retbuffer; |
99 | |
100 | /* get the address from the controller */ |
101 | retbuffer = bus_to_virt(mbox.bufstart); |
102 | switch (retbuffer[0]) { |
103 | case STATUS_OK: |
104 | ... |
105 | |
106 | on the other hand, you want the bus address when you have a buffer that |
107 | you want to give to the controller: |
108 | |
109 | /* ask the controller to read the sense status into "sense_buffer" */ |
110 | mbox.bufstart = virt_to_bus(&sense_buffer); |
111 | mbox.buflen = sizeof(sense_buffer); |
112 | mbox.status = 0; |
113 | notify_controller(&mbox); |
114 | |
115 | And you generally _never_ want to use the physical address, because you can't |
116 | use that from the CPU (the CPU only uses translated virtual addresses), and |
117 | you can't use it from the bus master. |
118 | |
119 | So why do we care about the physical address at all? We do need the physical |
120 | address in some cases, it's just not very often in normal code. The physical |
121 | address is needed if you use memory mappings, for example, because the |
122 | "remap_pfn_range()" mm function wants the physical address of the memory to |
123 | be remapped as measured in units of pages, a.k.a. the pfn (the memory |
124 | management layer doesn't know about devices outside the CPU, so it |
125 | shouldn't need to know about "bus addresses" etc). |
126 | |
127 | NOTE NOTE NOTE! The above is only one part of the whole equation. The above |
128 | only talks about "real memory", that is, CPU memory (RAM). |
129 | |
130 | There is a completely different type of memory too, and that's the "shared |
131 | memory" on the PCI or ISA bus. That's generally not RAM (although in the case |
132 | of a video graphics card it can be normal DRAM that is just used for a frame |
133 | buffer), but can be things like a packet buffer in a network card etc. |
134 | |
135 | This memory is called "PCI memory" or "shared memory" or "IO memory" or |
136 | whatever, and there is only one way to access it: the readb/writeb and |
137 | related functions. You should never take the address of such memory, because |
138 | there is really nothing you can do with such an address: it's not |
139 | conceptually in the same memory space as "real memory" at all, so you cannot |
140 | just dereference a pointer. (Sadly, on x86 it _is_ in the same memory space, |
141 | so on x86 it actually works to just deference a pointer, but it's not |
142 | portable). |
143 | |
144 | For such memory, you can do things like |
145 | |
146 | - reading: |
147 | /* |
148 | * read first 32 bits from ISA memory at 0xC0000, aka |
149 | * C000:0000 in DOS terms |
150 | */ |
151 | unsigned int signature = isa_readl(0xC0000); |
152 | |
153 | - remapping and writing: |
154 | /* |
155 | * remap framebuffer PCI memory area at 0xFC000000, |
156 | * size 1MB, so that we can access it: We can directly |
157 | * access only the 640k-1MB area, so anything else |
158 | * has to be remapped. |
159 | */ |
160 | char * baseptr = ioremap(0xFC000000, 1024*1024); |
161 | |
162 | /* write a 'A' to the offset 10 of the area */ |
163 | writeb('A',baseptr+10); |
164 | |
165 | /* unmap when we unload the driver */ |
166 | iounmap(baseptr); |
167 | |
168 | - copying and clearing: |
169 | /* get the 6-byte Ethernet address at ISA address E000:0040 */ |
170 | memcpy_fromio(kernel_buffer, 0xE0040, 6); |
171 | /* write a packet to the driver */ |
172 | memcpy_toio(0xE1000, skb->data, skb->len); |
173 | /* clear the frame buffer */ |
174 | memset_io(0xA0000, 0, 0x10000); |
175 | |
176 | OK, that just about covers the basics of accessing IO portably. Questions? |
177 | Comments? You may think that all the above is overly complex, but one day you |
178 | might find yourself with a 500 MHz Alpha in front of you, and then you'll be |
179 | happy that your driver works ;) |
180 | |
181 | Note that kernel versions 2.0.x (and earlier) mistakenly called the |
182 | ioremap() function "vremap()". ioremap() is the proper name, but I |
183 | didn't think straight when I wrote it originally. People who have to |
184 | support both can do something like: |
185 | |
186 | /* support old naming silliness */ |
187 | #if LINUX_VERSION_CODE < 0x020100 |
188 | #define ioremap vremap |
189 | #define iounmap vfree |
190 | #endif |
191 | |
192 | at the top of their source files, and then they can use the right names |
193 | even on 2.0.x systems. |
194 | |
195 | And the above sounds worse than it really is. Most real drivers really |
196 | don't do all that complex things (or rather: the complexity is not so |
197 | much in the actual IO accesses as in error handling and timeouts etc). |
198 | It's generally not hard to fix drivers, and in many cases the code |
199 | actually looks better afterwards: |
200 | |
201 | unsigned long signature = *(unsigned int *) 0xC0000; |
202 | vs |
203 | unsigned long signature = readl(0xC0000); |
204 | |
205 | I think the second version actually is more readable, no? |
206 | |
207 | Linus |
208 |