diff options
author | David S. Miller <davem@davemloft.net> | 2008-11-07 01:43:03 -0500 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2008-11-07 01:43:03 -0500 |
commit | 9eeda9abd1faf489f3df9a1f557975f4c8650363 (patch) | |
tree | 3e0a58e25b776cfbee193195460324dccb1886c7 /Documentation/io-mapping.txt | |
parent | 61c9eaf90081cbe6dc4f389e0056bff76eca19ec (diff) | |
parent | 4bab0ea1d42dd1927af9df6fbf0003fc00617c50 (diff) |
Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
Conflicts:
drivers/net/wireless/ath5k/base.c
net/8021q/vlan_core.c
Diffstat (limited to 'Documentation/io-mapping.txt')
-rw-r--r-- | Documentation/io-mapping.txt | 82 |
1 files changed, 82 insertions, 0 deletions
diff --git a/Documentation/io-mapping.txt b/Documentation/io-mapping.txt new file mode 100644 index 000000000000..473e43b2d588 --- /dev/null +++ b/Documentation/io-mapping.txt | |||
@@ -0,0 +1,82 @@ | |||
1 | The io_mapping functions in linux/io-mapping.h provide an abstraction for | ||
2 | efficiently mapping small regions of an I/O device to the CPU. The initial | ||
3 | usage is to support the large graphics aperture on 32-bit processors where | ||
4 | ioremap_wc cannot be used to statically map the entire aperture to the CPU | ||
5 | as it would consume too much of the kernel address space. | ||
6 | |||
7 | A mapping object is created during driver initialization using | ||
8 | |||
9 | struct io_mapping *io_mapping_create_wc(unsigned long base, | ||
10 | unsigned long size) | ||
11 | |||
12 | 'base' is the bus address of the region to be made | ||
13 | mappable, while 'size' indicates how large a mapping region to | ||
14 | enable. Both are in bytes. | ||
15 | |||
16 | This _wc variant provides a mapping which may only be used | ||
17 | with the io_mapping_map_atomic_wc or io_mapping_map_wc. | ||
18 | |||
19 | With this mapping object, individual pages can be mapped either atomically | ||
20 | or not, depending on the necessary scheduling environment. Of course, atomic | ||
21 | maps are more efficient: | ||
22 | |||
23 | void *io_mapping_map_atomic_wc(struct io_mapping *mapping, | ||
24 | unsigned long offset) | ||
25 | |||
26 | 'offset' is the offset within the defined mapping region. | ||
27 | Accessing addresses beyond the region specified in the | ||
28 | creation function yields undefined results. Using an offset | ||
29 | which is not page aligned yields an undefined result. The | ||
30 | return value points to a single page in CPU address space. | ||
31 | |||
32 | This _wc variant returns a write-combining map to the | ||
33 | page and may only be used with mappings created by | ||
34 | io_mapping_create_wc | ||
35 | |||
36 | Note that the task may not sleep while holding this page | ||
37 | mapped. | ||
38 | |||
39 | void io_mapping_unmap_atomic(void *vaddr) | ||
40 | |||
41 | 'vaddr' must be the the value returned by the last | ||
42 | io_mapping_map_atomic_wc call. This unmaps the specified | ||
43 | page and allows the task to sleep once again. | ||
44 | |||
45 | If you need to sleep while holding the lock, you can use the non-atomic | ||
46 | variant, although they may be significantly slower. | ||
47 | |||
48 | void *io_mapping_map_wc(struct io_mapping *mapping, | ||
49 | unsigned long offset) | ||
50 | |||
51 | This works like io_mapping_map_atomic_wc except it allows | ||
52 | the task to sleep while holding the page mapped. | ||
53 | |||
54 | void io_mapping_unmap(void *vaddr) | ||
55 | |||
56 | This works like io_mapping_unmap_atomic, except it is used | ||
57 | for pages mapped with io_mapping_map_wc. | ||
58 | |||
59 | At driver close time, the io_mapping object must be freed: | ||
60 | |||
61 | void io_mapping_free(struct io_mapping *mapping) | ||
62 | |||
63 | Current Implementation: | ||
64 | |||
65 | The initial implementation of these functions uses existing mapping | ||
66 | mechanisms and so provides only an abstraction layer and no new | ||
67 | functionality. | ||
68 | |||
69 | On 64-bit processors, io_mapping_create_wc calls ioremap_wc for the whole | ||
70 | range, creating a permanent kernel-visible mapping to the resource. The | ||
71 | map_atomic and map functions add the requested offset to the base of the | ||
72 | virtual address returned by ioremap_wc. | ||
73 | |||
74 | On 32-bit processors with HIGHMEM defined, io_mapping_map_atomic_wc uses | ||
75 | kmap_atomic_pfn to map the specified page in an atomic fashion; | ||
76 | kmap_atomic_pfn isn't really supposed to be used with device pages, but it | ||
77 | provides an efficient mapping for this usage. | ||
78 | |||
79 | On 32-bit processors without HIGHMEM defined, io_mapping_map_atomic_wc and | ||
80 | io_mapping_map_wc both use ioremap_wc, a terribly inefficient function which | ||
81 | performs an IPI to inform all processors about the new mapping. This results | ||
82 | in a significant performance penalty. | ||