Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 1 | Dynamic DMA mapping using the generic device |
| 2 | ============================================ |
| 3 | |
| 4 | James E.J. Bottomley <James.Bottomley@HansenPartnership.com> |
| 5 | |
| 6 | This document describes the DMA API. For a more gentle introduction |
| 7 | phrased in terms of the pci_ equivalents (and actual examples) see |
Randy Dunlap | 5872fb9 | 2009-01-29 16:28:02 -0800 | [diff] [blame] | 8 | Documentation/PCI/PCI-DMA-mapping.txt. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 9 | |
| 10 | This API is split into two pieces. Part I describes the API and the |
| 11 | corresponding pci_ API. Part II describes the extensions to the API |
| 12 | for supporting non-consistent memory machines. Unless you know that |
| 13 | your driver absolutely has to support non-consistent platforms (this |
| 14 | is usually only legacy platforms) you should only use the API |
| 15 | described in part I. |
| 16 | |
| 17 | Part I - pci_ and dma_ Equivalent API |
| 18 | ------------------------------------- |
| 19 | |
| 20 | To get the pci_ API, you must #include <linux/pci.h> |
| 21 | To get the dma_ API, you must #include <linux/dma-mapping.h> |
| 22 | |
| 23 | |
| 24 | Part Ia - Using large dma-coherent buffers |
| 25 | ------------------------------------------ |
| 26 | |
| 27 | void * |
| 28 | dma_alloc_coherent(struct device *dev, size_t size, |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 29 | dma_addr_t *dma_handle, gfp_t flag) |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 30 | void * |
| 31 | pci_alloc_consistent(struct pci_dev *dev, size_t size, |
| 32 | dma_addr_t *dma_handle) |
| 33 | |
| 34 | Consistent memory is memory for which a write by either the device or |
| 35 | the processor can immediately be read by the processor or device |
David Brownell | 21440d3 | 2006-04-01 10:21:52 -0800 | [diff] [blame] | 36 | without having to worry about caching effects. (You may however need |
| 37 | to make sure to flush the processor's write buffers before telling |
| 38 | devices to read that memory.) |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 39 | |
| 40 | This routine allocates a region of <size> bytes of consistent memory. |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 41 | It also returns a <dma_handle> which may be cast to an unsigned |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 42 | integer the same width as the bus and used as the physical address |
| 43 | base of the region. |
| 44 | |
| 45 | Returns: a pointer to the allocated region (in the processor's virtual |
| 46 | address space) or NULL if the allocation failed. |
| 47 | |
| 48 | Note: consistent memory can be expensive on some platforms, and the |
| 49 | minimum allocation length may be as big as a page, so you should |
| 50 | consolidate your requests for consistent memory as much as possible. |
| 51 | The simplest way to do that is to use the dma_pool calls (see below). |
| 52 | |
| 53 | The flag parameter (dma_alloc_coherent only) allows the caller to |
| 54 | specify the GFP_ flags (see kmalloc) for the allocation (the |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 55 | implementation may choose to ignore flags that affect the location of |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 56 | the returned memory, like GFP_DMA). For pci_alloc_consistent, you |
| 57 | must assume GFP_ATOMIC behaviour. |
| 58 | |
| 59 | void |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 60 | dma_free_coherent(struct device *dev, size_t size, void *cpu_addr, |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 61 | dma_addr_t dma_handle) |
| 62 | void |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 63 | pci_free_consistent(struct pci_dev *dev, size_t size, void *cpu_addr, |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 64 | dma_addr_t dma_handle) |
| 65 | |
| 66 | Free the region of consistent memory you previously allocated. dev, |
| 67 | size and dma_handle must all be the same as those passed into the |
| 68 | consistent allocate. cpu_addr must be the virtual address returned by |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 69 | the consistent allocate. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 70 | |
David Brownell | aa24886 | 2007-08-10 13:10:27 -0700 | [diff] [blame] | 71 | Note that unlike their sibling allocation calls, these routines |
| 72 | may only be called with IRQs enabled. |
| 73 | |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 74 | |
| 75 | Part Ib - Using small dma-coherent buffers |
| 76 | ------------------------------------------ |
| 77 | |
| 78 | To get this part of the dma_ API, you must #include <linux/dmapool.h> |
| 79 | |
| 80 | Many drivers need lots of small dma-coherent memory regions for DMA |
| 81 | descriptors or I/O buffers. Rather than allocating in units of a page |
| 82 | or more using dma_alloc_coherent(), you can use DMA pools. These work |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 83 | much like a struct kmem_cache, except that they use the dma-coherent allocator, |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 84 | not __get_free_pages(). Also, they understand common hardware constraints |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 85 | for alignment, like queue heads needing to be aligned on N-byte boundaries. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 86 | |
| 87 | |
| 88 | struct dma_pool * |
| 89 | dma_pool_create(const char *name, struct device *dev, |
| 90 | size_t size, size_t align, size_t alloc); |
| 91 | |
| 92 | struct pci_pool * |
| 93 | pci_pool_create(const char *name, struct pci_device *dev, |
| 94 | size_t size, size_t align, size_t alloc); |
| 95 | |
| 96 | The pool create() routines initialize a pool of dma-coherent buffers |
| 97 | for use with a given device. It must be called in a context which |
| 98 | can sleep. |
| 99 | |
Christoph Lameter | e18b890 | 2006-12-06 20:33:20 -0800 | [diff] [blame] | 100 | The "name" is for diagnostics (like a struct kmem_cache name); dev and size |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 101 | are like what you'd pass to dma_alloc_coherent(). The device's hardware |
| 102 | alignment requirement for this type of data is "align" (which is expressed |
| 103 | in bytes, and must be a power of two). If your device has no boundary |
| 104 | crossing restrictions, pass 0 for alloc; passing 4096 says memory allocated |
| 105 | from this pool must not cross 4KByte boundaries. |
| 106 | |
| 107 | |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 108 | void *dma_pool_alloc(struct dma_pool *pool, gfp_t gfp_flags, |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 109 | dma_addr_t *dma_handle); |
| 110 | |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 111 | void *pci_pool_alloc(struct pci_pool *pool, gfp_t gfp_flags, |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 112 | dma_addr_t *dma_handle); |
| 113 | |
| 114 | This allocates memory from the pool; the returned memory will meet the size |
| 115 | and alignment requirements specified at creation time. Pass GFP_ATOMIC to |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 116 | prevent blocking, or if it's permitted (not in_interrupt, not holding SMP locks), |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 117 | pass GFP_KERNEL to allow blocking. Like dma_alloc_coherent(), this returns |
| 118 | two values: an address usable by the cpu, and the dma address usable by the |
| 119 | pool's device. |
| 120 | |
| 121 | |
| 122 | void dma_pool_free(struct dma_pool *pool, void *vaddr, |
| 123 | dma_addr_t addr); |
| 124 | |
| 125 | void pci_pool_free(struct pci_pool *pool, void *vaddr, |
| 126 | dma_addr_t addr); |
| 127 | |
| 128 | This puts memory back into the pool. The pool is what was passed to |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 129 | the pool allocation routine; the cpu (vaddr) and dma addresses are what |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 130 | were returned when that routine allocated the memory being freed. |
| 131 | |
| 132 | |
| 133 | void dma_pool_destroy(struct dma_pool *pool); |
| 134 | |
| 135 | void pci_pool_destroy(struct pci_pool *pool); |
| 136 | |
| 137 | The pool destroy() routines free the resources of the pool. They must be |
| 138 | called in a context which can sleep. Make sure you've freed all allocated |
| 139 | memory back to the pool before you destroy it. |
| 140 | |
| 141 | |
| 142 | Part Ic - DMA addressing limitations |
| 143 | ------------------------------------ |
| 144 | |
| 145 | int |
| 146 | dma_supported(struct device *dev, u64 mask) |
| 147 | int |
Randy Dunlap | 02d15c4 | 2008-04-29 01:00:35 -0700 | [diff] [blame] | 148 | pci_dma_supported(struct pci_dev *hwdev, u64 mask) |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 149 | |
| 150 | Checks to see if the device can support DMA to the memory described by |
| 151 | mask. |
| 152 | |
| 153 | Returns: 1 if it can and 0 if it can't. |
| 154 | |
| 155 | Notes: This routine merely tests to see if the mask is possible. It |
| 156 | won't change the current mask settings. It is more intended as an |
| 157 | internal API for use by the platform than an external API for use by |
| 158 | driver writers. |
| 159 | |
| 160 | int |
| 161 | dma_set_mask(struct device *dev, u64 mask) |
| 162 | int |
| 163 | pci_set_dma_mask(struct pci_device *dev, u64 mask) |
| 164 | |
| 165 | Checks to see if the mask is possible and updates the device |
| 166 | parameters if it is. |
| 167 | |
| 168 | Returns: 0 if successful and a negative error if not. |
| 169 | |
FUJITA Tomonori | 6a1961f | 2010-03-10 15:23:39 -0800 | [diff] [blame^] | 170 | int |
| 171 | dma_set_coherent_mask(struct device *dev, u64 mask) |
| 172 | int |
| 173 | pci_set_consistent_dma_mask(struct pci_device *dev, u64 mask) |
| 174 | |
| 175 | Checks to see if the mask is possible and updates the device |
| 176 | parameters if it is. |
| 177 | |
| 178 | Returns: 0 if successful and a negative error if not. |
| 179 | |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 180 | u64 |
| 181 | dma_get_required_mask(struct device *dev) |
| 182 | |
John Keller | 175add1 | 2008-11-24 16:47:17 -0600 | [diff] [blame] | 183 | This API returns the mask that the platform requires to |
| 184 | operate efficiently. Usually this means the returned mask |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 185 | is the minimum required to cover all of memory. Examining the |
| 186 | required mask gives drivers with variable descriptor sizes the |
| 187 | opportunity to use smaller descriptors as necessary. |
| 188 | |
| 189 | Requesting the required mask does not alter the current mask. If you |
John Keller | 175add1 | 2008-11-24 16:47:17 -0600 | [diff] [blame] | 190 | wish to take advantage of it, you should issue a dma_set_mask() |
| 191 | call to set the mask to the value returned. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 192 | |
| 193 | |
| 194 | Part Id - Streaming DMA mappings |
| 195 | -------------------------------- |
| 196 | |
| 197 | dma_addr_t |
| 198 | dma_map_single(struct device *dev, void *cpu_addr, size_t size, |
| 199 | enum dma_data_direction direction) |
| 200 | dma_addr_t |
Randy Dunlap | 02d15c4 | 2008-04-29 01:00:35 -0700 | [diff] [blame] | 201 | pci_map_single(struct pci_dev *hwdev, void *cpu_addr, size_t size, |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 202 | int direction) |
| 203 | |
| 204 | Maps a piece of processor virtual memory so it can be accessed by the |
| 205 | device and returns the physical handle of the memory. |
| 206 | |
| 207 | The direction for both api's may be converted freely by casting. |
| 208 | However the dma_ API uses a strongly typed enumerator for its |
| 209 | direction: |
| 210 | |
| 211 | DMA_NONE = PCI_DMA_NONE no direction (used for |
| 212 | debugging) |
| 213 | DMA_TO_DEVICE = PCI_DMA_TODEVICE data is going from the |
| 214 | memory to the device |
| 215 | DMA_FROM_DEVICE = PCI_DMA_FROMDEVICE data is coming from |
| 216 | the device to the |
| 217 | memory |
| 218 | DMA_BIDIRECTIONAL = PCI_DMA_BIDIRECTIONAL direction isn't known |
| 219 | |
| 220 | Notes: Not all memory regions in a machine can be mapped by this |
| 221 | API. Further, regions that appear to be physically contiguous in |
| 222 | kernel virtual space may not be contiguous as physical memory. Since |
| 223 | this API does not provide any scatter/gather capability, it will fail |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 224 | if the user tries to map a non-physically contiguous piece of memory. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 225 | For this reason, it is recommended that memory mapped by this API be |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 226 | obtained only from sources which guarantee it to be physically contiguous |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 227 | (like kmalloc). |
| 228 | |
| 229 | Further, the physical address of the memory must be within the |
| 230 | dma_mask of the device (the dma_mask represents a bit mask of the |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 231 | addressable region for the device. I.e., if the physical address of |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 232 | the memory anded with the dma_mask is still equal to the physical |
| 233 | address, then the device can perform DMA to the memory). In order to |
| 234 | ensure that the memory allocated by kmalloc is within the dma_mask, |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 235 | the driver may specify various platform-dependent flags to restrict |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 236 | the physical memory range of the allocation (e.g. on x86, GFP_DMA |
| 237 | guarantees to be within the first 16Mb of available physical memory, |
| 238 | as required by ISA devices). |
| 239 | |
| 240 | Note also that the above constraints on physical contiguity and |
| 241 | dma_mask may not apply if the platform has an IOMMU (a device which |
| 242 | supplies a physical to virtual mapping between the I/O memory bus and |
| 243 | the device). However, to be portable, device driver writers may *not* |
| 244 | assume that such an IOMMU exists. |
| 245 | |
| 246 | Warnings: Memory coherency operates at a granularity called the cache |
| 247 | line width. In order for memory mapped by this API to operate |
| 248 | correctly, the mapped region must begin exactly on a cache line |
| 249 | boundary and end exactly on one (to prevent two separately mapped |
| 250 | regions from sharing a single cache line). Since the cache line size |
| 251 | may not be known at compile time, the API will not enforce this |
| 252 | requirement. Therefore, it is recommended that driver writers who |
| 253 | don't take special care to determine the cache line size at run time |
| 254 | only map virtual regions that begin and end on page boundaries (which |
| 255 | are guaranteed also to be cache line boundaries). |
| 256 | |
| 257 | DMA_TO_DEVICE synchronisation must be done after the last modification |
| 258 | of the memory region by the software and before it is handed off to |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 259 | the driver. Once this primitive is used, memory covered by this |
| 260 | primitive should be treated as read-only by the device. If the device |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 261 | may write to it at any point, it should be DMA_BIDIRECTIONAL (see |
| 262 | below). |
| 263 | |
| 264 | DMA_FROM_DEVICE synchronisation must be done before the driver |
| 265 | accesses data that may be changed by the device. This memory should |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 266 | be treated as read-only by the driver. If the driver needs to write |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 267 | to it at any point, it should be DMA_BIDIRECTIONAL (see below). |
| 268 | |
| 269 | DMA_BIDIRECTIONAL requires special handling: it means that the driver |
| 270 | isn't sure if the memory was modified before being handed off to the |
| 271 | device and also isn't sure if the device will also modify it. Thus, |
| 272 | you must always sync bidirectional memory twice: once before the |
| 273 | memory is handed off to the device (to make sure all memory changes |
| 274 | are flushed from the processor) and once before the data may be |
| 275 | accessed after being used by the device (to make sure any processor |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 276 | cache lines are updated with data that the device may have changed). |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 277 | |
| 278 | void |
| 279 | dma_unmap_single(struct device *dev, dma_addr_t dma_addr, size_t size, |
| 280 | enum dma_data_direction direction) |
| 281 | void |
| 282 | pci_unmap_single(struct pci_dev *hwdev, dma_addr_t dma_addr, |
| 283 | size_t size, int direction) |
| 284 | |
| 285 | Unmaps the region previously mapped. All the parameters passed in |
| 286 | must be identical to those passed in (and returned) by the mapping |
| 287 | API. |
| 288 | |
| 289 | dma_addr_t |
| 290 | dma_map_page(struct device *dev, struct page *page, |
| 291 | unsigned long offset, size_t size, |
| 292 | enum dma_data_direction direction) |
| 293 | dma_addr_t |
| 294 | pci_map_page(struct pci_dev *hwdev, struct page *page, |
| 295 | unsigned long offset, size_t size, int direction) |
| 296 | void |
| 297 | dma_unmap_page(struct device *dev, dma_addr_t dma_address, size_t size, |
| 298 | enum dma_data_direction direction) |
| 299 | void |
| 300 | pci_unmap_page(struct pci_dev *hwdev, dma_addr_t dma_address, |
| 301 | size_t size, int direction) |
| 302 | |
| 303 | API for mapping and unmapping for pages. All the notes and warnings |
| 304 | for the other mapping APIs apply here. Also, although the <offset> |
| 305 | and <size> parameters are provided to do partial page mapping, it is |
| 306 | recommended that you never use these unless you really know what the |
| 307 | cache width is. |
| 308 | |
| 309 | int |
FUJITA Tomonori | 8d8bb39 | 2008-07-25 19:44:49 -0700 | [diff] [blame] | 310 | dma_mapping_error(struct device *dev, dma_addr_t dma_addr) |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 311 | |
| 312 | int |
FUJITA Tomonori | 8d8bb39 | 2008-07-25 19:44:49 -0700 | [diff] [blame] | 313 | pci_dma_mapping_error(struct pci_dev *hwdev, dma_addr_t dma_addr) |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 314 | |
| 315 | In some circumstances dma_map_single and dma_map_page will fail to create |
| 316 | a mapping. A driver can check for these errors by testing the returned |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 317 | dma address with dma_mapping_error(). A non-zero return value means the mapping |
| 318 | could not be created and the driver should take appropriate action (e.g. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 319 | reduce current DMA mapping usage or delay and try again later). |
| 320 | |
David Brownell | 21440d3 | 2006-04-01 10:21:52 -0800 | [diff] [blame] | 321 | int |
| 322 | dma_map_sg(struct device *dev, struct scatterlist *sg, |
| 323 | int nents, enum dma_data_direction direction) |
| 324 | int |
| 325 | pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg, |
| 326 | int nents, int direction) |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 327 | |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 328 | Returns: the number of physical segments mapped (this may be shorter |
FUJITA Tomonori | 1d678f3 | 2008-12-01 13:14:01 -0800 | [diff] [blame] | 329 | than <nents> passed in if some elements of the scatter/gather list are |
| 330 | physically or virtually adjacent and an IOMMU maps them with a single |
| 331 | entry). |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 332 | |
| 333 | Please note that the sg cannot be mapped again if it has been mapped once. |
| 334 | The mapping process is allowed to destroy information in the sg. |
| 335 | |
| 336 | As with the other mapping interfaces, dma_map_sg can fail. When it |
| 337 | does, 0 is returned and a driver must take appropriate action. It is |
| 338 | critical that the driver do something, in the case of a block driver |
| 339 | aborting the request or even oopsing is better than doing nothing and |
| 340 | corrupting the filesystem. |
| 341 | |
David Brownell | 21440d3 | 2006-04-01 10:21:52 -0800 | [diff] [blame] | 342 | With scatterlists, you use the resulting mapping like this: |
| 343 | |
| 344 | int i, count = dma_map_sg(dev, sglist, nents, direction); |
| 345 | struct scatterlist *sg; |
| 346 | |
FUJITA Tomonori | 79eb014 | 2008-09-18 09:35:28 -0700 | [diff] [blame] | 347 | for_each_sg(sglist, sg, count, i) { |
David Brownell | 21440d3 | 2006-04-01 10:21:52 -0800 | [diff] [blame] | 348 | hw_address[i] = sg_dma_address(sg); |
| 349 | hw_len[i] = sg_dma_len(sg); |
| 350 | } |
| 351 | |
| 352 | where nents is the number of entries in the sglist. |
| 353 | |
| 354 | The implementation is free to merge several consecutive sglist entries |
| 355 | into one (e.g. with an IOMMU, or if several pages just happen to be |
| 356 | physically contiguous) and returns the actual number of sg entries it |
| 357 | mapped them to. On failure 0, is returned. |
| 358 | |
| 359 | Then you should loop count times (note: this can be less than nents times) |
| 360 | and use sg_dma_address() and sg_dma_len() macros where you previously |
| 361 | accessed sg->address and sg->length as shown above. |
| 362 | |
| 363 | void |
| 364 | dma_unmap_sg(struct device *dev, struct scatterlist *sg, |
| 365 | int nhwentries, enum dma_data_direction direction) |
| 366 | void |
| 367 | pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg, |
| 368 | int nents, int direction) |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 369 | |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 370 | Unmap the previously mapped scatter/gather list. All the parameters |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 371 | must be the same as those and passed in to the scatter/gather mapping |
| 372 | API. |
| 373 | |
| 374 | Note: <nents> must be the number you passed in, *not* the number of |
| 375 | physical entries returned. |
| 376 | |
FUJITA Tomonori | 9705ef7 | 2010-03-10 15:23:17 -0800 | [diff] [blame] | 377 | void |
| 378 | dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle, size_t size, |
| 379 | enum dma_data_direction direction) |
| 380 | void |
| 381 | pci_dma_sync_single_for_cpu(struct pci_dev *hwdev, dma_addr_t dma_handle, |
| 382 | size_t size, int direction) |
| 383 | void |
| 384 | dma_sync_single_for_device(struct device *dev, dma_addr_t dma_handle, size_t size, |
| 385 | enum dma_data_direction direction) |
| 386 | void |
| 387 | pci_dma_sync_single_for_device(struct pci_dev *hwdev, dma_addr_t dma_handle, |
| 388 | size_t size, int direction) |
| 389 | void |
| 390 | dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, int nelems, |
| 391 | enum dma_data_direction direction) |
| 392 | void |
| 393 | pci_dma_sync_sg_for_cpu(struct pci_dev *hwdev, struct scatterlist *sg, |
| 394 | int nelems, int direction) |
| 395 | void |
| 396 | dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nelems, |
| 397 | enum dma_data_direction direction) |
| 398 | void |
| 399 | pci_dma_sync_sg_for_device(struct pci_dev *hwdev, struct scatterlist *sg, |
| 400 | int nelems, int direction) |
| 401 | |
| 402 | Synchronise a single contiguous or scatter/gather mapping for the cpu |
| 403 | and device. With the sync_sg API, all the parameters must be the same |
| 404 | as those passed into the single mapping API. With the sync_single API, |
| 405 | you can use dma_handle and size parameters that aren't identical to |
| 406 | those passed into the single mapping API to do a partial sync. |
| 407 | |
| 408 | Notes: You must do this: |
| 409 | |
| 410 | - Before reading values that have been written by DMA from the device |
| 411 | (use the DMA_FROM_DEVICE direction) |
| 412 | - After writing values that will be written to the device using DMA |
| 413 | (use the DMA_TO_DEVICE) direction |
| 414 | - before *and* after handing memory to the device if the memory is |
| 415 | DMA_BIDIRECTIONAL |
| 416 | |
| 417 | See also dma_map_single(). |
| 418 | |
Arthur Kepner | a75b0a2 | 2008-04-29 01:00:31 -0700 | [diff] [blame] | 419 | dma_addr_t |
| 420 | dma_map_single_attrs(struct device *dev, void *cpu_addr, size_t size, |
| 421 | enum dma_data_direction dir, |
| 422 | struct dma_attrs *attrs) |
| 423 | |
| 424 | void |
| 425 | dma_unmap_single_attrs(struct device *dev, dma_addr_t dma_addr, |
| 426 | size_t size, enum dma_data_direction dir, |
| 427 | struct dma_attrs *attrs) |
| 428 | |
| 429 | int |
| 430 | dma_map_sg_attrs(struct device *dev, struct scatterlist *sgl, |
| 431 | int nents, enum dma_data_direction dir, |
| 432 | struct dma_attrs *attrs) |
| 433 | |
| 434 | void |
| 435 | dma_unmap_sg_attrs(struct device *dev, struct scatterlist *sgl, |
| 436 | int nents, enum dma_data_direction dir, |
| 437 | struct dma_attrs *attrs) |
| 438 | |
| 439 | The four functions above are just like the counterpart functions |
| 440 | without the _attrs suffixes, except that they pass an optional |
| 441 | struct dma_attrs*. |
| 442 | |
| 443 | struct dma_attrs encapsulates a set of "dma attributes". For the |
| 444 | definition of struct dma_attrs see linux/dma-attrs.h. |
| 445 | |
| 446 | The interpretation of dma attributes is architecture-specific, and |
| 447 | each attribute should be documented in Documentation/DMA-attributes.txt. |
| 448 | |
| 449 | If struct dma_attrs* is NULL, the semantics of each of these |
| 450 | functions is identical to those of the corresponding function |
| 451 | without the _attrs suffix. As a result dma_map_single_attrs() |
| 452 | can generally replace dma_map_single(), etc. |
| 453 | |
| 454 | As an example of the use of the *_attrs functions, here's how |
| 455 | you could pass an attribute DMA_ATTR_FOO when mapping memory |
| 456 | for DMA: |
| 457 | |
| 458 | #include <linux/dma-attrs.h> |
| 459 | /* DMA_ATTR_FOO should be defined in linux/dma-attrs.h and |
| 460 | * documented in Documentation/DMA-attributes.txt */ |
| 461 | ... |
| 462 | |
| 463 | DEFINE_DMA_ATTRS(attrs); |
| 464 | dma_set_attr(DMA_ATTR_FOO, &attrs); |
| 465 | .... |
| 466 | n = dma_map_sg_attrs(dev, sg, nents, DMA_TO_DEVICE, &attr); |
| 467 | .... |
| 468 | |
| 469 | Architectures that care about DMA_ATTR_FOO would check for its |
| 470 | presence in their implementations of the mapping and unmapping |
| 471 | routines, e.g.: |
| 472 | |
| 473 | void whizco_dma_map_sg_attrs(struct device *dev, dma_addr_t dma_addr, |
| 474 | size_t size, enum dma_data_direction dir, |
| 475 | struct dma_attrs *attrs) |
| 476 | { |
| 477 | .... |
| 478 | int foo = dma_get_attr(DMA_ATTR_FOO, attrs); |
| 479 | .... |
| 480 | if (foo) |
| 481 | /* twizzle the frobnozzle */ |
| 482 | .... |
| 483 | |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 484 | |
FUJITA Tomonori | 0acedc1 | 2010-03-10 15:23:31 -0800 | [diff] [blame] | 485 | Part Ie - Optimizing Unmap State Space Consumption |
| 486 | -------------------------------- |
| 487 | |
| 488 | On some platforms, dma_unmap_{single,page}() is simply a nop. |
| 489 | Therefore, keeping track of the mapping address and length is a waste |
| 490 | of space. Instead of filling your drivers up with ifdefs and the like |
| 491 | to "work around" this (which would defeat the whole purpose of a |
| 492 | portable API) the following facilities are provided. |
| 493 | |
| 494 | Actually, instead of describing the macros one by one, we'll |
| 495 | transform some example code. |
| 496 | |
| 497 | 1) Use DEFINE_DMA_UNMAP_{ADDR,LEN} in state saving structures. |
| 498 | Example, before: |
| 499 | |
| 500 | struct ring_state { |
| 501 | struct sk_buff *skb; |
| 502 | dma_addr_t mapping; |
| 503 | __u32 len; |
| 504 | }; |
| 505 | |
| 506 | after: |
| 507 | |
| 508 | struct ring_state { |
| 509 | struct sk_buff *skb; |
| 510 | DEFINE_DMA_UNMAP_ADDR(mapping); |
| 511 | DEFINE_DMA_UNMAP_LEN(len); |
| 512 | }; |
| 513 | |
| 514 | 2) Use dma_unmap_{addr,len}_set to set these values. |
| 515 | Example, before: |
| 516 | |
| 517 | ringp->mapping = FOO; |
| 518 | ringp->len = BAR; |
| 519 | |
| 520 | after: |
| 521 | |
| 522 | dma_unmap_addr_set(ringp, mapping, FOO); |
| 523 | dma_unmap_len_set(ringp, len, BAR); |
| 524 | |
| 525 | 3) Use dma_unmap_{addr,len} to access these values. |
| 526 | Example, before: |
| 527 | |
| 528 | dma_unmap_single(dev, ringp->mapping, ringp->len, |
| 529 | DMA_FROM_DEVICE); |
| 530 | |
| 531 | after: |
| 532 | |
| 533 | dma_unmap_single(dev, |
| 534 | dma_unmap_addr(ringp, mapping), |
| 535 | dma_unmap_len(ringp, len), |
| 536 | DMA_FROM_DEVICE); |
| 537 | |
| 538 | It really should be self-explanatory. We treat the ADDR and LEN |
| 539 | separately, because it is possible for an implementation to only |
| 540 | need the address in order to perform the unmap operation. |
| 541 | |
| 542 | |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 543 | Part II - Advanced dma_ usage |
| 544 | ----------------------------- |
| 545 | |
| 546 | Warning: These pieces of the DMA API have no PCI equivalent. They |
| 547 | should also not be used in the majority of cases, since they cater for |
| 548 | unlikely corner cases that don't belong in usual drivers. |
| 549 | |
| 550 | If you don't understand how cache line coherency works between a |
| 551 | processor and an I/O device, you should not be using this part of the |
| 552 | API at all. |
| 553 | |
| 554 | void * |
| 555 | dma_alloc_noncoherent(struct device *dev, size_t size, |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 556 | dma_addr_t *dma_handle, gfp_t flag) |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 557 | |
| 558 | Identical to dma_alloc_coherent() except that the platform will |
| 559 | choose to return either consistent or non-consistent memory as it sees |
| 560 | fit. By using this API, you are guaranteeing to the platform that you |
| 561 | have all the correct and necessary sync points for this memory in the |
| 562 | driver should it choose to return non-consistent memory. |
| 563 | |
| 564 | Note: where the platform can return consistent memory, it will |
| 565 | guarantee that the sync points become nops. |
| 566 | |
| 567 | Warning: Handling non-consistent memory is a real pain. You should |
| 568 | only ever use this API if you positively know your driver will be |
| 569 | required to work on one of the rare (usually non-PCI) architectures |
| 570 | that simply cannot make consistent memory. |
| 571 | |
| 572 | void |
| 573 | dma_free_noncoherent(struct device *dev, size_t size, void *cpu_addr, |
| 574 | dma_addr_t dma_handle) |
| 575 | |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 576 | Free memory allocated by the nonconsistent API. All parameters must |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 577 | be identical to those passed in (and returned by |
| 578 | dma_alloc_noncoherent()). |
| 579 | |
| 580 | int |
Ralf Baechle | f67637e | 2006-12-06 20:38:54 -0800 | [diff] [blame] | 581 | dma_is_consistent(struct device *dev, dma_addr_t dma_handle) |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 582 | |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 583 | Returns true if the device dev is performing consistent DMA on the memory |
Ralf Baechle | f67637e | 2006-12-06 20:38:54 -0800 | [diff] [blame] | 584 | area pointed to by the dma_handle. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 585 | |
| 586 | int |
| 587 | dma_get_cache_alignment(void) |
| 588 | |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 589 | Returns the processor cache alignment. This is the absolute minimum |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 590 | alignment *and* width that you must observe when either mapping |
| 591 | memory or doing partial flushes. |
| 592 | |
| 593 | Notes: This API may return a number *larger* than the actual cache |
| 594 | line, but it will guarantee that one or more cache lines fit exactly |
| 595 | into the width returned by this call. It will also always be a power |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 596 | of two for easy alignment. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 597 | |
| 598 | void |
Ralf Baechle | d3fa72e | 2006-12-06 20:38:56 -0800 | [diff] [blame] | 599 | dma_cache_sync(struct device *dev, void *vaddr, size_t size, |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 600 | enum dma_data_direction direction) |
| 601 | |
| 602 | Do a partial sync of memory that was allocated by |
| 603 | dma_alloc_noncoherent(), starting at virtual address vaddr and |
| 604 | continuing on for size. Again, you *must* observe the cache line |
| 605 | boundaries when doing this. |
| 606 | |
| 607 | int |
| 608 | dma_declare_coherent_memory(struct device *dev, dma_addr_t bus_addr, |
| 609 | dma_addr_t device_addr, size_t size, int |
| 610 | flags) |
| 611 | |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 612 | Declare region of memory to be handed out by dma_alloc_coherent when |
| 613 | it's asked for coherent memory for this device. |
| 614 | |
| 615 | bus_addr is the physical address to which the memory is currently |
| 616 | assigned in the bus responding region (this will be used by the |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 617 | platform to perform the mapping). |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 618 | |
| 619 | device_addr is the physical address the device needs to be programmed |
| 620 | with actually to address this memory (this will be handed out as the |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 621 | dma_addr_t in dma_alloc_coherent()). |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 622 | |
| 623 | size is the size of the area (must be multiples of PAGE_SIZE). |
| 624 | |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 625 | flags can be or'd together and are: |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 626 | |
| 627 | DMA_MEMORY_MAP - request that the memory returned from |
Matt LaPlante | 4ae0edc | 2006-11-30 04:58:40 +0100 | [diff] [blame] | 628 | dma_alloc_coherent() be directly writable. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 629 | |
| 630 | DMA_MEMORY_IO - request that the memory returned from |
| 631 | dma_alloc_coherent() be addressable using read/write/memcpy_toio etc. |
| 632 | |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 633 | One or both of these flags must be present. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 634 | |
| 635 | DMA_MEMORY_INCLUDES_CHILDREN - make the declared memory be allocated by |
| 636 | dma_alloc_coherent of any child devices of this one (for memory residing |
| 637 | on a bridge). |
| 638 | |
| 639 | DMA_MEMORY_EXCLUSIVE - only allocate memory from the declared regions. |
| 640 | Do not allow dma_alloc_coherent() to fall back to system memory when |
| 641 | it's out of memory in the declared region. |
| 642 | |
| 643 | The return value will be either DMA_MEMORY_MAP or DMA_MEMORY_IO and |
| 644 | must correspond to a passed in flag (i.e. no returning DMA_MEMORY_IO |
| 645 | if only DMA_MEMORY_MAP were passed in) for success or zero for |
| 646 | failure. |
| 647 | |
| 648 | Note, for DMA_MEMORY_IO returns, all subsequent memory returned by |
| 649 | dma_alloc_coherent() may no longer be accessed directly, but instead |
| 650 | must be accessed using the correct bus functions. If your driver |
| 651 | isn't prepared to handle this contingency, it should not specify |
| 652 | DMA_MEMORY_IO in the input flags. |
| 653 | |
| 654 | As a simplification for the platforms, only *one* such region of |
| 655 | memory may be declared per device. |
| 656 | |
| 657 | For reasons of efficiency, most platforms choose to track the declared |
| 658 | region only at the granularity of a page. For smaller allocations, |
| 659 | you should use the dma_pool() API. |
| 660 | |
| 661 | void |
| 662 | dma_release_declared_memory(struct device *dev) |
| 663 | |
| 664 | Remove the memory region previously declared from the system. This |
| 665 | API performs *no* in-use checking for this region and will return |
| 666 | unconditionally having removed all the required structures. It is the |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 667 | driver's job to ensure that no parts of this memory region are |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 668 | currently in use. |
| 669 | |
| 670 | void * |
| 671 | dma_mark_declared_memory_occupied(struct device *dev, |
| 672 | dma_addr_t device_addr, size_t size) |
| 673 | |
| 674 | This is used to occupy specific regions of the declared space |
| 675 | (dma_alloc_coherent() will hand out the first free region it finds). |
| 676 | |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 677 | device_addr is the *device* address of the region requested. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 678 | |
Randy Dunlap | a12e2c6 | 2007-07-31 00:38:17 -0700 | [diff] [blame] | 679 | size is the size (and should be a page-sized multiple). |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 680 | |
| 681 | The return value will be either a pointer to the processor virtual |
| 682 | address of the memory, or an error (via PTR_ERR()) if any part of the |
| 683 | region is occupied. |
Joerg Roedel | 187f9c3 | 2009-01-09 16:28:07 +0100 | [diff] [blame] | 684 | |
| 685 | Part III - Debug drivers use of the DMA-API |
| 686 | ------------------------------------------- |
| 687 | |
| 688 | The DMA-API as described above as some constraints. DMA addresses must be |
| 689 | released with the corresponding function with the same size for example. With |
| 690 | the advent of hardware IOMMUs it becomes more and more important that drivers |
| 691 | do not violate those constraints. In the worst case such a violation can |
| 692 | result in data corruption up to destroyed filesystems. |
| 693 | |
| 694 | To debug drivers and find bugs in the usage of the DMA-API checking code can |
| 695 | be compiled into the kernel which will tell the developer about those |
| 696 | violations. If your architecture supports it you can select the "Enable |
| 697 | debugging of DMA-API usage" option in your kernel configuration. Enabling this |
| 698 | option has a performance impact. Do not enable it in production kernels. |
| 699 | |
| 700 | If you boot the resulting kernel will contain code which does some bookkeeping |
| 701 | about what DMA memory was allocated for which device. If this code detects an |
| 702 | error it prints a warning message with some details into your kernel log. An |
| 703 | example warning message may look like this: |
| 704 | |
| 705 | ------------[ cut here ]------------ |
| 706 | WARNING: at /data2/repos/linux-2.6-iommu/lib/dma-debug.c:448 |
| 707 | check_unmap+0x203/0x490() |
| 708 | Hardware name: |
| 709 | forcedeth 0000:00:08.0: DMA-API: device driver frees DMA memory with wrong |
| 710 | function [device address=0x00000000640444be] [size=66 bytes] [mapped as |
| 711 | single] [unmapped as page] |
| 712 | Modules linked in: nfsd exportfs bridge stp llc r8169 |
| 713 | Pid: 0, comm: swapper Tainted: G W 2.6.28-dmatest-09289-g8bb99c0 #1 |
| 714 | Call Trace: |
| 715 | <IRQ> [<ffffffff80240b22>] warn_slowpath+0xf2/0x130 |
| 716 | [<ffffffff80647b70>] _spin_unlock+0x10/0x30 |
| 717 | [<ffffffff80537e75>] usb_hcd_link_urb_to_ep+0x75/0xc0 |
| 718 | [<ffffffff80647c22>] _spin_unlock_irqrestore+0x12/0x40 |
| 719 | [<ffffffff8055347f>] ohci_urb_enqueue+0x19f/0x7c0 |
| 720 | [<ffffffff80252f96>] queue_work+0x56/0x60 |
| 721 | [<ffffffff80237e10>] enqueue_task_fair+0x20/0x50 |
| 722 | [<ffffffff80539279>] usb_hcd_submit_urb+0x379/0xbc0 |
| 723 | [<ffffffff803b78c3>] cpumask_next_and+0x23/0x40 |
| 724 | [<ffffffff80235177>] find_busiest_group+0x207/0x8a0 |
| 725 | [<ffffffff8064784f>] _spin_lock_irqsave+0x1f/0x50 |
| 726 | [<ffffffff803c7ea3>] check_unmap+0x203/0x490 |
| 727 | [<ffffffff803c8259>] debug_dma_unmap_page+0x49/0x50 |
| 728 | [<ffffffff80485f26>] nv_tx_done_optimized+0xc6/0x2c0 |
| 729 | [<ffffffff80486c13>] nv_nic_irq_optimized+0x73/0x2b0 |
| 730 | [<ffffffff8026df84>] handle_IRQ_event+0x34/0x70 |
| 731 | [<ffffffff8026ffe9>] handle_edge_irq+0xc9/0x150 |
| 732 | [<ffffffff8020e3ab>] do_IRQ+0xcb/0x1c0 |
| 733 | [<ffffffff8020c093>] ret_from_intr+0x0/0xa |
| 734 | <EOI> <4>---[ end trace f6435a98e2a38c0e ]--- |
| 735 | |
| 736 | The driver developer can find the driver and the device including a stacktrace |
| 737 | of the DMA-API call which caused this warning. |
| 738 | |
| 739 | Per default only the first error will result in a warning message. All other |
| 740 | errors will only silently counted. This limitation exist to prevent the code |
| 741 | from flooding your kernel log. To support debugging a device driver this can |
| 742 | be disabled via debugfs. See the debugfs interface documentation below for |
| 743 | details. |
| 744 | |
| 745 | The debugfs directory for the DMA-API debugging code is called dma-api/. In |
| 746 | this directory the following files can currently be found: |
| 747 | |
| 748 | dma-api/all_errors This file contains a numeric value. If this |
| 749 | value is not equal to zero the debugging code |
| 750 | will print a warning for every error it finds |
Matt LaPlante | 19f5946 | 2009-04-27 15:06:31 +0200 | [diff] [blame] | 751 | into the kernel log. Be careful with this |
| 752 | option, as it can easily flood your logs. |
Joerg Roedel | 187f9c3 | 2009-01-09 16:28:07 +0100 | [diff] [blame] | 753 | |
| 754 | dma-api/disabled This read-only file contains the character 'Y' |
| 755 | if the debugging code is disabled. This can |
| 756 | happen when it runs out of memory or if it was |
| 757 | disabled at boot time |
| 758 | |
| 759 | dma-api/error_count This file is read-only and shows the total |
| 760 | numbers of errors found. |
| 761 | |
| 762 | dma-api/num_errors The number in this file shows how many |
| 763 | warnings will be printed to the kernel log |
| 764 | before it stops. This number is initialized to |
| 765 | one at system boot and be set by writing into |
| 766 | this file |
| 767 | |
| 768 | dma-api/min_free_entries |
| 769 | This read-only file can be read to get the |
| 770 | minimum number of free dma_debug_entries the |
| 771 | allocator has ever seen. If this value goes |
| 772 | down to zero the code will disable itself |
| 773 | because it is not longer reliable. |
| 774 | |
| 775 | dma-api/num_free_entries |
| 776 | The current number of free dma_debug_entries |
| 777 | in the allocator. |
| 778 | |
Joerg Roedel | 016ea68 | 2009-05-22 21:57:23 +0200 | [diff] [blame] | 779 | dma-api/driver-filter |
| 780 | You can write a name of a driver into this file |
| 781 | to limit the debug output to requests from that |
| 782 | particular driver. Write an empty string to |
| 783 | that file to disable the filter and see |
| 784 | all errors again. |
| 785 | |
Joerg Roedel | 187f9c3 | 2009-01-09 16:28:07 +0100 | [diff] [blame] | 786 | If you have this code compiled into your kernel it will be enabled by default. |
| 787 | If you want to boot without the bookkeeping anyway you can provide |
| 788 | 'dma_debug=off' as a boot parameter. This will disable DMA-API debugging. |
| 789 | Notice that you can not enable it again at runtime. You have to reboot to do |
| 790 | so. |
| 791 | |
Joerg Roedel | 016ea68 | 2009-05-22 21:57:23 +0200 | [diff] [blame] | 792 | If you want to see debug messages only for a special device driver you can |
| 793 | specify the dma_debug_driver=<drivername> parameter. This will enable the |
| 794 | driver filter at boot time. The debug code will only print errors for that |
| 795 | driver afterwards. This filter can be disabled or changed later using debugfs. |
| 796 | |
Joerg Roedel | 187f9c3 | 2009-01-09 16:28:07 +0100 | [diff] [blame] | 797 | When the code disables itself at runtime this is most likely because it ran |
| 798 | out of dma_debug_entries. These entries are preallocated at boot. The number |
| 799 | of preallocated entries is defined per architecture. If it is too low for you |
| 800 | boot with 'dma_debug_entries=<your_desired_number>' to overwrite the |
| 801 | architectural default. |