Root/
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. |
83 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9