diff options
| -rw-r--r-- | Documentation/DMA-API-HOWTO.txt | 8 | ||||
| -rw-r--r-- | Documentation/DMA-API.txt | 12 |
2 files changed, 10 insertions, 10 deletions
diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index fd3727b94ac..f5995530347 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 4f1cdc5febd..52088408668 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 |