AcoSail/kernel_optimize_test
8
0
Fork 0
forked from luck/tmp_suning_uos_patched
Code Pull Requests Activity

DMA-API: Capitalize "CPU" consistently

Browse Source 
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>
This commit is contained in:
Bjorn Helgaas 2014-05-20 16:56:27 -06:00
parent ace4b3fd67
commit f311a724a7
2 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
Documentation/DMA-API-HOWTO.txt
View File

@ -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);

12
Documentation/DMA-API.txt
View File

@ -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