Lines Matching +full:dma +full:- +full:capable
2 Dynamic DMA mapping Guide
9 This is a guide to device driver writers on how to use the DMA API
10 with example pseudo-code. For a concise description of the API, see
11 DMA-API.txt.
13 CPU and DMA addresses
16 There are several kinds of addresses involved in the DMA API, and it's
31 registers at an MMIO address, or if it performs DMA to read or write system
37 From a device's point of view, DMA uses the bus address space, but it may
39 supports 64-bit addresses for main memory and PCI BARs, it may use an IOMMU
40 so devices only need to use 32-bit DMA addresses.
49 +-------+ +------+ +------+
52 C +-------+ --------> B +------+ ----------> +------+ A
54 +-----+ | | | | bridge | | +--------+
55 | | | | +------+ | | | |
58 +-----+ +-------+ +------+ +------+ +--------+
60 X +-------+ --------> Y +------+ <---------- +------+ Z
64 +-------+ +------+
75 If the device supports DMA, the driver sets up a buffer using kmalloc() or
79 cannot because DMA doesn't go through the CPU virtual memory system.
81 In some simple systems, the device can do DMA directly to physical address
82 Y. But in many others, there is IOMMU hardware that translates DMA
84 of the reason for the DMA API: the driver can give a virtual address X to
86 mapping and returns the DMA address Z. The driver then tells the device to
87 do DMA to Z, and the IOMMU maps it to the buffer at address Y in system
90 So that Linux can use the dynamic DMA mapping, it needs some help from the
91 drivers, namely it has to take into account that DMA addresses should be
92 mapped only for the time they are actually used and unmapped after the DMA
98 Note that the DMA API works with any bus independent of the underlying
99 microprocessor architecture. You should use the DMA API rather than the
100 bus-specific DMA API, i.e., use the dma_map_*() interfaces rather than the
105 #include <linux/dma-mapping.h>
108 can hold any valid DMA address for the platform and should be used
109 everywhere you hold a DMA address returned from the DMA mapping functions.
111 What memory is DMA'able?
115 be used with the DMA mapping facilities. There has been an unwritten
121 (i.e. kmalloc() or kmem_cache_alloc()) then you may DMA to/from
125 returned from vmalloc() for DMA. It is possible to DMA to the
134 stack addresses for DMA. These could all be mapped somewhere entirely
136 memory could physically work with DMA, you'd need to ensure the I/O
137 buffers were cacheline-aligned. Without that, you'd see cacheline
138 sharing problems (data corruption) on CPUs with DMA-incoherent caches.
139 (The CPU could write to one word, DMA would write to a different one
143 call and DMA to/from that. This is similar to vmalloc().
147 for you to DMA from/to.
149 DMA addressing limitations
152 Does your device have any DMA addressing limitations? For example, is
153 your device only capable of driving the low order 24-bits of address?
157 32-bits. For a 64-bit capable device, this needs to be increased.
161 Special note about PCI: PCI-X specification requires PCI-X devices to
162 support 64-bit addressing (DAC) for all transactions. And at least
163 one platform (SGI SN2) requires 64-bit consistent allocations to
164 operate correctly when the IO bus is in PCI-X mode.
167 probe routine to see if the DMA controller on the machine can properly
168 support the DMA addressing limitation your device has. It is good
193 supports. It returns zero if your card can perform DMA properly on
195 device struct of your device is embedded in the bus-specific device
196 struct of your device. For example, &pdev->dev is a pointer to the
200 If it returns non-zero, your device cannot perform DMA properly on
202 behavior. You must either use a different mask, or not use DMA.
206 1) Use another DMA mask, if possible (see below).
207 2) Use some non-DMA mode for data transfer, if possible.
216 The standard 32-bit addressing device would do something like this::
219 dev_warn(dev, "mydev: No suitable DMA available\n");
223 Another common scenario is a 64-bit capable device. The approach here
224 is to try for 64-bit addressing, but back down to a 32-bit mask that
225 should not fail. The kernel may fail the 64-bit mask not because the
226 platform is not capable of 64-bit addressing. Rather, it may fail in
227 this case simply because 32-bit addressing is done more efficiently
228 than 64-bit addressing. For example, Sparc64 PCI SAC addressing is
231 Here is how you would handle a 64-bit capable device which can drive
232 all 64-bits when accessing streaming DMA::
241 dev_warn(dev, "mydev: No suitable DMA available\n");
245 If a card is capable of using 64-bit consistent allocations as well,
257 dev_warn(dev, "mydev: No suitable DMA available\n");
266 Finally, if your device can only drive the low 24-bits of
270 dev_warn(dev, "mydev: 24-bit DMA addressing not available\n");
276 kernel will use this information later when you make DMA mappings.
282 DMA addressing limitations, you may wish to probe each mask and
287 Here is pseudo-code showing how this might be done::
297 card->playback_enabled = 1;
299 card->playback_enabled = 0;
300 dev_warn(dev, "%s: Playback disabled due to DMA limitations\n",
301 card->name);
304 card->record_enabled = 1;
306 card->record_enabled = 0;
307 dev_warn(dev, "%s: Record disabled due to DMA limitations\n",
308 card->name);
313 and thus retaining the 16MB DMA addressing limitations of ISA.
315 Types of DMA mappings
318 There are two types of DMA mappings:
320 - Consistent DMA mappings which are usually mapped at driver
329 bits of the DMA space. However, for future compatibility you should
335 - Network card DMA ring descriptors.
336 - SCSI adapter mailbox command data structures.
337 - Device firmware microcode executed out of
346 Consistent DMA memory does not preclude the usage of
353 desc->word0 = address;
355 desc->word1 = DESC_VALID;
364 - Streaming DMA mappings which are usually mapped for one DMA
373 - Networking buffers transmitted/received by a device.
374 - Filesystem buffers written/read by a SCSI device.
381 Neither type of DMA mapping has alignment restrictions that come from
383 Also, systems with caches that aren't DMA-coherent will work better
387 Using Consistent DMA mappings
390 To allocate and map large (PAGE_SIZE or so) consistent DMA regions,
407 The consistent DMA mapping interfaces, for non-NULL dev, will by
408 default return a DMA address which is 32-bit addressable. Even if the
409 device indicates (via DMA mask) that it may address the upper 32-bits,
410 consistent allocation will only return > 32-bit addresses for DMA if
411 the consistent DMA mask has been explicitly changed via
419 The CPU virtual address and the DMA address are both
426 To unmap and free such a DMA region, you call::
455 Allocate memory from a DMA pool like this::
479 DMA Direction
483 take a DMA direction argument, which is an integer and takes on
491 You should provide the exact DMA direction if you know it.
495 It is the direction in which the data moves during the DMA
501 If you absolutely cannot know the direction of the DMA transfer,
502 specify DMA_BIDIRECTIONAL. It means that the DMA can go in
513 potential platform-specific optimizations of such) is for debugging.
514 Some platforms actually have a write permission boolean which DMA
517 kernel logs when the DMA controller hardware detects violation of the
533 Using Streaming DMA mappings
536 The streaming DMA mapping routines can be called from interrupt
543 struct device *dev = &my_dev->dev;
545 void *addr = buffer->ptr;
546 size_t size = buffer->len;
551 * reduce current DMA mapping usage,
564 DMA implementations without any dependency on the specifics of the underlying
569 You should call dma_unmap_single() when the DMA activity is finished, e.g.,
570 from the interrupt which told you that the DMA transfer is done.
578 struct device *dev = &my_dev->dev;
580 struct page *page = buffer->page;
581 unsigned long offset = buffer->offset;
582 size_t size = buffer->len;
587 * reduce current DMA mapping usage,
603 You should call dma_unmap_page() when the DMA activity is finished, e.g.,
604 from the interrupt which told you that the DMA transfer is done.
619 into one (e.g. if DMA mapping is done with PAGE_SIZE granularity, any
621 ends and the second one starts on a page boundary - in fact this is a huge
622 advantage for cards which either cannot do scatter-gather or have very
623 limited number of scatter-gather entries) and returns the actual number
628 accessed sg->address and sg->length as shown above.
634 Again, make sure DMA activity has already finished.
644 counterpart, because the DMA address space is a shared resource and
645 you could render the machine unusable by consuming all DMA addresses.
647 If you need to use the same streaming DMA region multiple times and touch
648 the data in between the DMA transfers, the buffer needs to be synced
649 properly in order for the CPU and device to see the most up-to-date and
650 correct copy of the DMA buffer.
652 So, firstly, just map it with dma_map_{single,sg}(), and after each DMA
663 Then, if you wish to let the device get at the DMA area again,
682 After the last DMA transfer call one of the DMA unmap routines
694 mapping = dma_map_single(cp->dev, buffer, len, DMA_FROM_DEVICE);
695 if (dma_mapping_error(cp->dev, mapping)) {
697 * reduce current DMA mapping usage,
704 cp->rx_buf = buffer;
705 cp->rx_len = len;
706 cp->rx_dma = mapping;
723 * the DMA transfer with the CPU first
726 dma_sync_single_for_cpu(&cp->dev, cp->rx_dma,
727 cp->rx_len,
731 hp = (struct my_card_header *) cp->rx_buf;
733 dma_unmap_single(&cp->dev, cp->rx_dma, cp->rx_len,
735 pass_to_upper_layers(cp->rx_buf);
739 * DMA_FROM_DEVICE-mapped area,
753 dynamic DMA mapping scheme - you have to always store the DMA addresses
756 supports dynamic DMA mapping in hardware) in your driver structures and/or
767 DMA address space is limited on some architectures and an allocation
770 - checking if dma_alloc_coherent() returns NULL or dma_map_sg returns 0
772 - checking the dma_addr_t returned from dma_map_single() and dma_map_page()
780 * reduce current DMA mapping usage,
787 - unmap pages that are already mapped, when mapping error occurs in the middle
799 * reduce current DMA mapping usage,
808 * reduce current DMA mapping usage,
839 * reduce current DMA mapping usage,
861 and return NETDEV_TX_OK if the DMA mapping fails on the transmit hook
865 SCSI drivers must return SCSI_MLQUEUE_HOST_BUSY if the DMA mapping
901 ringp->mapping = FOO;
902 ringp->len = BAR;
912 dma_unmap_single(dev, ringp->mapping, ringp->len,
922 It really should be self-explanatory. We treat the ADDR and LEN
941 DMA-safe. Drivers and subsystems depend on it. If an architecture
942 isn't fully DMA-coherent (i.e. hardware doesn't ensure that data in
948 Note that ARCH_DMA_MINALIGN is about DMA memory alignment
950 alignment constraints (e.g. the alignment constraints about 64-bit
969 David Mosberger-Tang <davidm@hpl.hp.com>