Lines Matching refs:DMA

2 over how DMA may be used to perform I/O operations.  The APIs are detailed
8 The big picture is that USB drivers can continue to ignore most DMA issues,
9 though they still must provide DMA-ready buffers (see
10 Documentation/DMA-API-HOWTO.txt).  That's how they've worked through
13 OR:  they can now be DMA-aware.
15 - New calls enable DMA-aware drivers, letting them allocate dma buffers and
22 - "usbcore" will map this DMA address, if a DMA-aware driver didn't do
26 - There's a new "generic DMA API", parts of which are usable by USB device
38   IOMMU to manage the DMA mappings.  It can cost MUCH more to set up and
58   not using a streaming DMA mapping, so it's good for small transfers on
60   Documentation/DMA-API-HOWTO.txt for definitions of "coherent" and
61   "streaming" DMA mappings.)
70   lines to prevent DMA conflicts.
72 - Devices on some EHCI controllers could handle DMA to/from high memory.
74   Unfortunately, the current Linux DMA infrastructure doesn't have a sane
81   high memory to "normal" DMA memory.  If you can come up with a good way
88 Existing buffers aren't usable for DMA without first being mapped into the
89 DMA address space of the device.  However, most buffers passed to your
90 driver can safely be used with such DMA mapping.  (See the first section
91 of Documentation/DMA-API-HOWTO.txt, titled "What memory is DMA-able?")
95   DMA transactions:
106   It's probably easier to use the new usb_sg_*() calls, which do the DMA
132 calls (where the underlying DMA primitives have changed), most of them can