Keith Packard | 9663f2e | 2008-10-30 19:38:18 -0700 | [diff] [blame] | 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 | |
Keith Packard | 8d5c660 | 2008-11-03 18:21:44 +0100 | [diff] [blame] | 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. |