mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-09-28 21:33:52 +00:00
usb/dma.txt: convert to ReST and add to driver-api book
This document describe some USB core features. Add it to the driver-api book. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
parent
3db5f406e4
commit
2a373331dd
2 changed files with 28 additions and 24 deletions
|
@ -1,16 +1,19 @@
|
||||||
|
USB DMA
|
||||||
|
~~~~~~~
|
||||||
|
|
||||||
In Linux 2.5 kernels (and later), USB device drivers have additional control
|
In Linux 2.5 kernels (and later), USB device drivers have additional control
|
||||||
over how DMA may be used to perform I/O operations. The APIs are detailed
|
over how DMA may be used to perform I/O operations. The APIs are detailed
|
||||||
in the kernel usb programming guide (kerneldoc, from the source code).
|
in the kernel usb programming guide (kerneldoc, from the source code).
|
||||||
|
|
||||||
|
API overview
|
||||||
API OVERVIEW
|
============
|
||||||
|
|
||||||
The big picture is that USB drivers can continue to ignore most DMA issues,
|
The big picture is that USB drivers can continue to ignore most DMA issues,
|
||||||
though they still must provide DMA-ready buffers (see
|
though they still must provide DMA-ready buffers (see
|
||||||
Documentation/DMA-API-HOWTO.txt). That's how they've worked through
|
``Documentation/DMA-API-HOWTO.txt``). That's how they've worked through
|
||||||
the 2.4 (and earlier) kernels.
|
the 2.4 (and earlier) kernels, or they can now be DMA-aware.
|
||||||
|
|
||||||
OR: they can now be DMA-aware.
|
DMA-aware usb drivers:
|
||||||
|
|
||||||
- New calls enable DMA-aware drivers, letting them allocate dma buffers and
|
- New calls enable DMA-aware drivers, letting them allocate dma buffers and
|
||||||
manage dma mappings for existing dma-ready buffers (see below).
|
manage dma mappings for existing dma-ready buffers (see below).
|
||||||
|
@ -20,15 +23,15 @@ OR: they can now be DMA-aware.
|
||||||
drivers must not use it.)
|
drivers must not use it.)
|
||||||
|
|
||||||
- "usbcore" will map this DMA address, if a DMA-aware driver didn't do
|
- "usbcore" will map this DMA address, if a DMA-aware driver didn't do
|
||||||
it first and set URB_NO_TRANSFER_DMA_MAP. HCDs
|
it first and set ``URB_NO_TRANSFER_DMA_MAP``. HCDs
|
||||||
don't manage dma mappings for URBs.
|
don't manage dma mappings for URBs.
|
||||||
|
|
||||||
- There's a new "generic DMA API", parts of which are usable by USB device
|
- There's a new "generic DMA API", parts of which are usable by USB device
|
||||||
drivers. Never use dma_set_mask() on any USB interface or device; that
|
drivers. Never use dma_set_mask() on any USB interface or device; that
|
||||||
would potentially break all devices sharing that bus.
|
would potentially break all devices sharing that bus.
|
||||||
|
|
||||||
|
Eliminating copies
|
||||||
ELIMINATING COPIES
|
==================
|
||||||
|
|
||||||
It's good to avoid making CPUs copy data needlessly. The costs can add up,
|
It's good to avoid making CPUs copy data needlessly. The costs can add up,
|
||||||
and effects like cache-trashing can impose subtle penalties.
|
and effects like cache-trashing can impose subtle penalties.
|
||||||
|
@ -41,7 +44,7 @@ and effects like cache-trashing can impose subtle penalties.
|
||||||
For those specific cases, USB has primitives to allocate less expensive
|
For those specific cases, USB has primitives to allocate less expensive
|
||||||
memory. They work like kmalloc and kfree versions that give you the right
|
memory. They work like kmalloc and kfree versions that give you the right
|
||||||
kind of addresses to store in urb->transfer_buffer and urb->transfer_dma.
|
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:
|
You'd also set ``URB_NO_TRANSFER_DMA_MAP`` in urb->transfer_flags::
|
||||||
|
|
||||||
void *usb_alloc_coherent (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);
|
int mem_flags, dma_addr_t *dma);
|
||||||
|
@ -49,15 +52,15 @@ and effects like cache-trashing can impose subtle penalties.
|
||||||
void usb_free_coherent (struct usb_device *dev, size_t size,
|
void usb_free_coherent (struct usb_device *dev, size_t size,
|
||||||
void *addr, dma_addr_t dma);
|
void *addr, dma_addr_t dma);
|
||||||
|
|
||||||
Most drivers should *NOT* be using these primitives; they don't need
|
Most drivers should **NOT** be using these primitives; they don't need
|
||||||
to use this type of memory ("dma-coherent"), and memory returned from
|
to use this type of memory ("dma-coherent"), and memory returned from
|
||||||
kmalloc() will work just fine.
|
:c:func:`kmalloc` will work just fine.
|
||||||
|
|
||||||
The memory buffer returned is "dma-coherent"; sometimes you might need to
|
The memory buffer returned is "dma-coherent"; sometimes you might need to
|
||||||
force a consistent memory access ordering by using memory barriers. It's
|
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
|
not using a streaming DMA mapping, so it's good for small transfers on
|
||||||
systems where the I/O would otherwise thrash an IOMMU mapping. (See
|
systems where the I/O would otherwise thrash an IOMMU mapping. (See
|
||||||
Documentation/DMA-API-HOWTO.txt for definitions of "coherent" and
|
``Documentation/DMA-API-HOWTO.txt`` for definitions of "coherent" and
|
||||||
"streaming" DMA mappings.)
|
"streaming" DMA mappings.)
|
||||||
|
|
||||||
Asking for 1/Nth of a page (as well as asking for N pages) is reasonably
|
Asking for 1/Nth of a page (as well as asking for N pages) is reasonably
|
||||||
|
@ -75,15 +78,15 @@ and effects like cache-trashing can impose subtle penalties.
|
||||||
way to expose these capabilities ... and in any case, HIGHMEM is mostly a
|
way to expose these capabilities ... and in any case, HIGHMEM is mostly a
|
||||||
design wart specific to x86_32. So your best bet is to ensure you never
|
design wart specific to x86_32. So your best bet is to ensure you never
|
||||||
pass a highmem buffer into a USB driver. That's easy; it's the default
|
pass a highmem buffer into a USB driver. That's easy; it's the default
|
||||||
behavior. Just don't override it; e.g. with NETIF_F_HIGHDMA.
|
behavior. Just don't override it; e.g. with ``NETIF_F_HIGHDMA``.
|
||||||
|
|
||||||
This may force your callers to do some bounce buffering, copying from
|
This may force your callers to do some bounce buffering, copying from
|
||||||
high memory to "normal" DMA memory. If you can come up with a good way
|
high memory to "normal" DMA memory. If you can come up with a good way
|
||||||
to fix this issue (for x86_32 machines with over 1 GByte of memory),
|
to fix this issue (for x86_32 machines with over 1 GByte of memory),
|
||||||
feel free to submit patches.
|
feel free to submit patches.
|
||||||
|
|
||||||
|
Working with existing buffers
|
||||||
WORKING WITH EXISTING BUFFERS
|
=============================
|
||||||
|
|
||||||
Existing buffers aren't usable for DMA without first being mapped into the
|
Existing buffers aren't usable for DMA without first being mapped into the
|
||||||
DMA address space of the device. However, most buffers passed to your
|
DMA address space of the device. However, most buffers passed to your
|
||||||
|
@ -92,7 +95,7 @@ of Documentation/DMA-API-HOWTO.txt, titled "What memory is DMA-able?")
|
||||||
|
|
||||||
- When you're using scatterlists, you can map everything at once. On some
|
- When you're using scatterlists, you can map everything at once. On some
|
||||||
systems, this kicks in an IOMMU and turns the scatterlists into single
|
systems, this kicks in an IOMMU and turns the scatterlists into single
|
||||||
DMA transactions:
|
DMA transactions::
|
||||||
|
|
||||||
int usb_buffer_map_sg (struct usb_device *dev, unsigned pipe,
|
int usb_buffer_map_sg (struct usb_device *dev, unsigned pipe,
|
||||||
struct scatterlist *sg, int nents);
|
struct scatterlist *sg, int nents);
|
||||||
|
@ -103,7 +106,7 @@ of Documentation/DMA-API-HOWTO.txt, titled "What memory is DMA-able?")
|
||||||
void usb_buffer_unmap_sg (struct usb_device *dev, unsigned pipe,
|
void usb_buffer_unmap_sg (struct usb_device *dev, unsigned pipe,
|
||||||
struct scatterlist *sg, int n_hw_ents);
|
struct scatterlist *sg, int n_hw_ents);
|
||||||
|
|
||||||
It's probably easier to use the new usb_sg_*() calls, which do the DMA
|
It's probably easier to use the new ``usb_sg_*()`` calls, which do the DMA
|
||||||
mapping and apply other tweaks to make scatterlist i/o be fast.
|
mapping and apply other tweaks to make scatterlist i/o be fast.
|
||||||
|
|
||||||
- Some drivers may prefer to work with the model that they're mapping large
|
- Some drivers may prefer to work with the model that they're mapping large
|
||||||
|
@ -112,10 +115,10 @@ of Documentation/DMA-API-HOWTO.txt, titled "What memory is DMA-able?")
|
||||||
here, since it's cheaper to just synchronize the buffer than to unmap it
|
here, since it's cheaper to just synchronize the buffer than to unmap it
|
||||||
each time an urb completes and then re-map it on during resubmission.
|
each time an urb completes and then re-map it on during resubmission.
|
||||||
|
|
||||||
These calls all work with initialized urbs: urb->dev, urb->pipe,
|
These calls all work with initialized urbs: ``urb->dev``, ``urb->pipe``,
|
||||||
urb->transfer_buffer, and urb->transfer_buffer_length must all be
|
``urb->transfer_buffer``, and ``urb->transfer_buffer_length`` must all be
|
||||||
valid when these calls are used (urb->setup_packet must be valid too
|
valid when these calls are used (``urb->setup_packet`` must be valid too
|
||||||
if urb is a control request):
|
if urb is a control request)::
|
||||||
|
|
||||||
struct urb *usb_buffer_map (struct urb *urb);
|
struct urb *usb_buffer_map (struct urb *urb);
|
||||||
|
|
||||||
|
@ -123,9 +126,9 @@ of Documentation/DMA-API-HOWTO.txt, titled "What memory is DMA-able?")
|
||||||
|
|
||||||
void usb_buffer_unmap (struct urb *urb);
|
void usb_buffer_unmap (struct urb *urb);
|
||||||
|
|
||||||
The calls manage urb->transfer_dma for you, and set URB_NO_TRANSFER_DMA_MAP
|
The calls manage ``urb->transfer_dma`` for you, and set
|
||||||
so that usbcore won't map or unmap the buffer. They cannot be used for
|
``URB_NO_TRANSFER_DMA_MAP`` so that usbcore won't map or unmap the buffer.
|
||||||
setup_packet buffers in control requests.
|
They cannot be used for setup_packet buffers in control requests.
|
||||||
|
|
||||||
Note that several of those interfaces are currently commented out, since
|
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
|
they don't have current users. See the source code. Other than the dmasync
|
|
@ -9,6 +9,7 @@ Linux USB API
|
||||||
anchors
|
anchors
|
||||||
bulk-streams
|
bulk-streams
|
||||||
callbacks
|
callbacks
|
||||||
|
dma
|
||||||
power-management
|
power-management
|
||||||
writing_usb_driver
|
writing_usb_driver
|
||||||
writing_musb_glue_layer
|
writing_musb_glue_layer
|
||||||
|
|
Loading…
Reference in a new issue