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>

2 files changed, 10 insertions, 10 deletions

diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index fd3727b94ac2..f59955303475 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -575,10 +575,10 @@ Incorrect example 2:
 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 @@ 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
 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 @@ or:
 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 4f1cdc5febd1..52088408668a 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -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.
 
 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 @@ size and alignment requirements specified at creation time.  Pass
 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 @@ device.
 			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 @@ void
 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 @@ 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
 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