diff options
Diffstat (limited to 'Documentation/usb/dma.txt')
| -rw-r--r-- | Documentation/usb/dma.txt | 22 |
1 files changed, 8 insertions, 14 deletions
diff --git a/Documentation/usb/dma.txt b/Documentation/usb/dma.txt index cfdcd16e3ab..84ef865237d 100644 --- a/Documentation/usb/dma.txt +++ b/Documentation/usb/dma.txt @@ -16,11 +16,11 @@ OR: they can now be DMA-aware. manage dma mappings for existing dma-ready buffers (see below). - URBs have an additional "transfer_dma" field, as well as a transfer_flags - bit saying if it's valid. (Control requests also have "setup_dma" and a - corresponding transfer_flags bit.) + bit saying if it's valid. (Control requests also have "setup_dma", but + drivers must not use it.) -- "usbcore" will map those DMA addresses, if a DMA-aware driver didn't do - it first and set URB_NO_TRANSFER_DMA_MAP or URB_NO_SETUP_DMA_MAP. HCDs +- "usbcore" will map this DMA address, if a DMA-aware driver didn't do + it first and set URB_NO_TRANSFER_DMA_MAP. HCDs don't manage dma mappings for URBs. - There's a new "generic DMA API", parts of which are usable by USB device @@ -43,22 +43,16 @@ and effects like cache-trashing can impose subtle penalties. kind of addresses to store in urb->transfer_buffer and urb->transfer_dma. You'd also set URB_NO_TRANSFER_DMA_MAP in urb->transfer_flags: - void *usb_buffer_alloc (struct usb_device *dev, size_t size, + void *usb_alloc_coherent (struct usb_device *dev, size_t size, int mem_flags, dma_addr_t *dma); - void usb_buffer_free (struct usb_device *dev, size_t size, + void usb_free_coherent (struct usb_device *dev, size_t size, void *addr, dma_addr_t dma); Most drivers should *NOT* be using these primitives; they don't need to use this type of memory ("dma-coherent"), and memory returned from kmalloc() will work just fine. - For control transfers you can use the buffer primitives or not for each - of the transfer buffer and setup buffer independently. Set the flag bits - URB_NO_TRANSFER_DMA_MAP and URB_NO_SETUP_DMA_MAP to indicate which - buffers you have prepared. For non-control transfers URB_NO_SETUP_DMA_MAP - is ignored. - The memory buffer returned is "dma-coherent"; sometimes you might need to force a consistent memory access ordering by using memory barriers. It's not using a streaming DMA mapping, so it's good for small transfers on @@ -130,8 +124,8 @@ of Documentation/PCI/PCI-DMA-mapping.txt, titled "What memory is DMA-able?") void usb_buffer_unmap (struct urb *urb); The calls manage urb->transfer_dma for you, and set URB_NO_TRANSFER_DMA_MAP - so that usbcore won't map or unmap the buffer. The same goes for - urb->setup_dma and URB_NO_SETUP_DMA_MAP for control requests. + so that usbcore won't map or unmap the buffer. They cannot be used for + setup_packet buffers in control requests. Note that several of those interfaces are currently commented out, since they don't have current users. See the source code. Other than the dmasync |