^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) USB DMA
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) ~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) In Linux 2.5 kernels (and later), USB device drivers have additional control
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) over how DMA may be used to perform I/O operations. The APIs are detailed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) in the kernel usb programming guide (kerneldoc, from the source code).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) API overview
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) ============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) The big picture is that USB drivers can continue to ignore most DMA issues,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) though they still must provide DMA-ready buffers (see
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) :doc:`/core-api/dma-api-howto`). That's how they've worked through
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) the 2.4 (and earlier) kernels, or they can now be DMA-aware.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) DMA-aware usb drivers:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) - New calls enable DMA-aware drivers, letting them allocate dma buffers and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) manage dma mappings for existing dma-ready buffers (see below).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) - URBs have an additional "transfer_dma" field, as well as a transfer_flags
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) bit saying if it's valid. (Control requests also have "setup_dma", but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) drivers must not use it.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) - "usbcore" will map this DMA address, if a DMA-aware driver didn't do
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) it first and set ``URB_NO_TRANSFER_DMA_MAP``. HCDs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) don't manage dma mappings for URBs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) - There's a new "generic DMA API", parts of which are usable by USB device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) drivers. Never use dma_set_mask() on any USB interface or device; that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) would potentially break all devices sharing that bus.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) Eliminating copies
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) ==================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) It's good to avoid making CPUs copy data needlessly. The costs can add up,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) and effects like cache-trashing can impose subtle penalties.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) - If you're doing lots of small data transfers from the same buffer all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) the time, that can really burn up resources on systems which use an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) IOMMU to manage the DMA mappings. It can cost MUCH more to set up and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) tear down the IOMMU mappings with each request than perform the I/O!
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) For those specific cases, USB has primitives to allocate less expensive
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) memory. They work like kmalloc and kfree versions that give you the right
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) kind of addresses to store in urb->transfer_buffer and urb->transfer_dma.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) You'd also set ``URB_NO_TRANSFER_DMA_MAP`` in urb->transfer_flags::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) void *usb_alloc_coherent (struct usb_device *dev, size_t size,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) int mem_flags, dma_addr_t *dma);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) void usb_free_coherent (struct usb_device *dev, size_t size,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) void *addr, dma_addr_t dma);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) Most drivers should **NOT** be using these primitives; they don't need
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) to use this type of memory ("dma-coherent"), and memory returned from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) :c:func:`kmalloc` will work just fine.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) The memory buffer returned is "dma-coherent"; sometimes you might need to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) force a consistent memory access ordering by using memory barriers. It's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) not using a streaming DMA mapping, so it's good for small transfers on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) systems where the I/O would otherwise thrash an IOMMU mapping. (See
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) :doc:`/core-api/dma-api-howto` for definitions of "coherent" and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) "streaming" DMA mappings.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) Asking for 1/Nth of a page (as well as asking for N pages) is reasonably
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) space-efficient.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) On most systems the memory returned will be uncached, because the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) semantics of dma-coherent memory require either bypassing CPU caches
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) or using cache hardware with bus-snooping support. While x86 hardware
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) has such bus-snooping, many other systems use software to flush cache
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) lines to prevent DMA conflicts.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) - Devices on some EHCI controllers could handle DMA to/from high memory.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) Unfortunately, the current Linux DMA infrastructure doesn't have a sane
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) way to expose these capabilities ... and in any case, HIGHMEM is mostly a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) design wart specific to x86_32. So your best bet is to ensure you never
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) pass a highmem buffer into a USB driver. That's easy; it's the default
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) behavior. Just don't override it; e.g. with ``NETIF_F_HIGHDMA``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) This may force your callers to do some bounce buffering, copying from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) high memory to "normal" DMA memory. If you can come up with a good way
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) to fix this issue (for x86_32 machines with over 1 GByte of memory),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) feel free to submit patches.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) Working with existing buffers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) =============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) Existing buffers aren't usable for DMA without first being mapped into the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) DMA address space of the device. However, most buffers passed to your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) driver can safely be used with such DMA mapping. (See the first section
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) of :doc:`/core-api/dma-api-howto`, titled "What memory is DMA-able?")
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) - When you're using scatterlists, you can map everything at once. On some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) systems, this kicks in an IOMMU and turns the scatterlists into single
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) DMA transactions::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) int usb_buffer_map_sg (struct usb_device *dev, unsigned pipe,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) struct scatterlist *sg, int nents);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) void usb_buffer_dmasync_sg (struct usb_device *dev, unsigned pipe,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) struct scatterlist *sg, int n_hw_ents);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) void usb_buffer_unmap_sg (struct usb_device *dev, unsigned pipe,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) struct scatterlist *sg, int n_hw_ents);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) It's probably easier to use the new ``usb_sg_*()`` calls, which do the DMA
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) mapping and apply other tweaks to make scatterlist i/o be fast.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) - Some drivers may prefer to work with the model that they're mapping large
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) buffers, synchronizing their safe re-use. (If there's no re-use, then let
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) usbcore do the map/unmap.) Large periodic transfers make good examples
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) here, since it's cheaper to just synchronize the buffer than to unmap it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) each time an urb completes and then re-map it on during resubmission.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) These calls all work with initialized urbs: ``urb->dev``, ``urb->pipe``,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) ``urb->transfer_buffer``, and ``urb->transfer_buffer_length`` must all be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) valid when these calls are used (``urb->setup_packet`` must be valid too
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) if urb is a control request)::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) struct urb *usb_buffer_map (struct urb *urb);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) void usb_buffer_dmasync (struct urb *urb);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) void usb_buffer_unmap (struct urb *urb);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) The calls manage ``urb->transfer_dma`` for you, and set
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) ``URB_NO_TRANSFER_DMA_MAP`` so that usbcore won't map or unmap the buffer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) They cannot be used for setup_packet buffers in control requests.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) Note that several of those interfaces are currently commented out, since
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) they don't have current users. See the source code. Other than the dmasync
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) calls (where the underlying DMA primitives have changed), most of them can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) easily be commented back in if you want to use them.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags