DMA-API: Capitalize "CPU" consistently
Sometimes we used "cpu," other times "CPU." Use "CPU" consistently.
Suggested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index fd3727b..f599553 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -575,10 +575,10 @@
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.
-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
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:
struct device *dev = &my_dev->dev;
@@ -650,7 +650,7 @@
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
-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.
So, firstly, just map it with dma_map_{single,sg}(), and after each DMA
@@ -665,7 +665,7 @@
as appropriate.
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:
dma_sync_single_for_device(dev, dma_handle, size, direction);
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 4f1cdc5..5208840 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -19,7 +19,7 @@
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
-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
its physical address space and the bus address space.
@@ -112,7 +112,7 @@
GFP_ATOMIC to prevent blocking, or if it's permitted (not
in_interrupt, not holding SMP locks), pass GFP_KERNEL to allow
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.
@@ -120,7 +120,7 @@
dma_addr_t addr);
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.
@@ -355,7 +355,7 @@
dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nelems,
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
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
@@ -504,8 +504,8 @@
Declare region of memory to be handed out by dma_alloc_coherent() when
it's asked for coherent memory for this device.
-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).
+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).
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