Commit f311a724 authored by Bjorn Helgaas's avatar Bjorn Helgaas

DMA-API: Capitalize "CPU" consistently

Sometimes we used "cpu," other times "CPU."  Use "CPU" consistently.
Suggested-by: default avatarRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
parent ace4b3fd
...@@ -575,10 +575,10 @@ Incorrect example 2: ...@@ -575,10 +575,10 @@ Incorrect example 2:
You should call dma_unmap_single() when the DMA activity is finished, e.g., You should call dma_unmap_single() when the DMA activity is finished, e.g.,
from the interrupt which told you that the DMA transfer is done. from the interrupt which told you that the DMA transfer is done.
Using cpu pointers like this for single mappings has a disadvantage: Using CPU pointers like this for single mappings has a disadvantage:
you cannot reference HIGHMEM memory in this way. Thus, there is a you cannot reference HIGHMEM memory in this way. Thus, there is a
map/unmap interface pair akin to dma_{map,unmap}_single(). These map/unmap interface pair akin to dma_{map,unmap}_single(). These
interfaces deal with page/offset pairs instead of cpu pointers. interfaces deal with page/offset pairs instead of CPU pointers.
Specifically: Specifically:
struct device *dev = &my_dev->dev; struct device *dev = &my_dev->dev;
...@@ -650,7 +650,7 @@ you could render the machine unusable by consuming all bus addresses. ...@@ -650,7 +650,7 @@ you could render the machine unusable by consuming all bus addresses.
If you need to use the same streaming DMA region multiple times and touch If you need to use the same streaming DMA region multiple times and touch
the data in between the DMA transfers, the buffer needs to be synced the data in between the DMA transfers, the buffer needs to be synced
properly in order for the cpu and device to see the most up-to-date and properly in order for the CPU and device to see the most up-to-date and
correct copy of the DMA buffer. correct copy of the DMA buffer.
So, firstly, just map it with dma_map_{single,sg}(), and after each DMA So, firstly, just map it with dma_map_{single,sg}(), and after each DMA
...@@ -665,7 +665,7 @@ or: ...@@ -665,7 +665,7 @@ or:
as appropriate. as appropriate.
Then, if you wish to let the device get at the DMA area again, Then, if you wish to let the device get at the DMA area again,
finish accessing the data with the cpu, and then before actually finish accessing the data with the CPU, and then before actually
giving the buffer to the hardware call either: giving the buffer to the hardware call either:
dma_sync_single_for_device(dev, dma_handle, size, direction); dma_sync_single_for_device(dev, dma_handle, size, direction);
......
...@@ -19,7 +19,7 @@ To get the dma_ API, you must #include <linux/dma-mapping.h>. This ...@@ -19,7 +19,7 @@ To get the dma_ API, you must #include <linux/dma-mapping.h>. This
provides dma_addr_t and the interfaces described below. provides dma_addr_t and the interfaces described below.
A dma_addr_t can hold any valid DMA or bus address for the platform. It A dma_addr_t can hold any valid DMA or bus address for the platform. It
can be given to a device to use as a DMA source or target. A cpu cannot can be given to a device to use as a DMA source or target. A CPU cannot
reference a dma_addr_t directly because there may be translation between reference a dma_addr_t directly because there may be translation between
its physical address space and the bus address space. its physical address space and the bus address space.
...@@ -112,7 +112,7 @@ size and alignment requirements specified at creation time. Pass ...@@ -112,7 +112,7 @@ size and alignment requirements specified at creation time. Pass
GFP_ATOMIC to prevent blocking, or if it's permitted (not GFP_ATOMIC to prevent blocking, or if it's permitted (not
in_interrupt, not holding SMP locks), pass GFP_KERNEL to allow in_interrupt, not holding SMP locks), pass GFP_KERNEL to allow
blocking. Like dma_alloc_coherent(), this returns two values: an blocking. Like dma_alloc_coherent(), this returns two values: an
address usable by the cpu, and the DMA address usable by the pool's address usable by the CPU, and the DMA address usable by the pool's
device. device.
...@@ -120,7 +120,7 @@ device. ...@@ -120,7 +120,7 @@ device.
dma_addr_t addr); dma_addr_t addr);
This puts memory back into the pool. The pool is what was passed to This puts memory back into the pool. The pool is what was passed to
dma_pool_alloc(); the cpu (vaddr) and DMA addresses are what dma_pool_alloc(); the CPU (vaddr) and DMA addresses are what
were returned when that routine allocated the memory being freed. were returned when that routine allocated the memory being freed.
...@@ -355,7 +355,7 @@ void ...@@ -355,7 +355,7 @@ void
dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nelems, dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nelems,
enum dma_data_direction direction) enum dma_data_direction direction)
Synchronise a single contiguous or scatter/gather mapping for the cpu Synchronise a single contiguous or scatter/gather mapping for the CPU
and device. With the sync_sg API, all the parameters must be the same and device. With the sync_sg API, all the parameters must be the same
as those passed into the single mapping API. With the sync_single API, as those passed into the single mapping API. With the sync_single API,
you can use dma_handle and size parameters that aren't identical to you can use dma_handle and size parameters that aren't identical to
...@@ -504,8 +504,8 @@ dma_declare_coherent_memory(struct device *dev, phys_addr_t phys_addr, ...@@ -504,8 +504,8 @@ dma_declare_coherent_memory(struct device *dev, phys_addr_t phys_addr,
Declare region of memory to be handed out by dma_alloc_coherent() when Declare region of memory to be handed out by dma_alloc_coherent() when
it's asked for coherent memory for this device. it's asked for coherent memory for this device.
phys_addr is the cpu physical address to which the memory is currently phys_addr is the CPU physical address to which the memory is currently
assigned (this will be ioremapped so the cpu can access the region). assigned (this will be ioremapped so the CPU can access the region).
device_addr is the bus address the device needs to be programmed device_addr is the bus address the device needs to be programmed
with to actually address this memory (this will be handed out as the with to actually address this memory (this will be handed out as the
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment