summaryrefslogtreecommitdiffstats
path: root/Documentation/usb
diff options
context:
space:
mode:
authorAlan Stern <stern@rowland.harvard.edu>2010-04-30 16:35:37 -0400
committerGreg Kroah-Hartman <gregkh@suse.de>2010-05-20 13:21:40 -0700
commit85bcb5ee889e0ebb9154718939e049de265fcdfb (patch)
treedaeec28274c8b68fea502c41af84d45d2681ebc5 /Documentation/usb
parent842f16905dfc6743c1dd80c3d29b49ba3ab7f7c8 (diff)
downloadop-kernel-dev-85bcb5ee889e0ebb9154718939e049de265fcdfb.zip
op-kernel-dev-85bcb5ee889e0ebb9154718939e049de265fcdfb.tar.gz
USB: remove URB_NO_SETUP_DMA_MAP
Now that URB_NO_SETUP_DMA_MAP is no longer in use, this patch (as1376) removes all references to it. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'Documentation/usb')
-rw-r--r--Documentation/usb/dma.txt18
1 files changed, 6 insertions, 12 deletions
diff --git a/Documentation/usb/dma.txt b/Documentation/usb/dma.txt
index a37e59c..84ef865 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
@@ -53,12 +53,6 @@ and effects like cache-trashing can impose subtle penalties.
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
OpenPOWER on IntegriCloud