patch-2.4.19 linux-2.4.19/Documentation/DMA-mapping.txt

• Lines: 105
• Date: Fri Aug 2 17:39:42 2002
• Orig file: linux-2.4.18/Documentation/DMA-mapping.txt
• Orig date: Mon Feb 25 11:37:51 2002

diff -urN linux-2.4.18/Documentation/DMA-mapping.txt linux-2.4.19/Documentation/DMA-mapping.txt
@@ -8,7 +8,7 @@
 Most of the 64bit platforms have special hardware that translates bus
 addresses (DMA addresses) into physical addresses.  This is similar to
 how page tables and/or a TLB translates virtual addresses to physical
-addresses on a cpu.  This is needed so that e.g. PCI devices can
+addresses on a CPU.  This is needed so that e.g. PCI devices can
 access with a Single Address Cycle (32bit DMA address) any page in the
 64bit physical address space.  Previously in Linux those 64bit
 platforms had to set artificial limits on the maximum RAM size in the
@@ -37,7 +37,7 @@
 			 What memory is DMA'able?
 
 The first piece of information you must know is what kernel memory can
-be used with the DMA mapping facilitites.  There has been an unwritten
+be used with the DMA mapping facilities.  There has been an unwritten
 set of rules regarding this, and this text is an attempt to finally
 write them down.
 
@@ -106,7 +106,7 @@
 3) Ignore this device and do not initialize it.
 
 It is recommended that your driver print a kernel KERN_WARNING message
-when you end up performing either #2 or #2.  In this manner, if a user
+when you end up performing either #2 or #3.  In this manner, if a user
 of your driver reports that performance is bad or that the device is not
 even detected, you can ask them for the kernel messages to find out
 exactly why.
@@ -146,7 +146,7 @@
 If your 64-bit device is going to be an enormous consumer of DMA
 mappings, this can be problematic since the DMA mappings are a
 finite resource on many platforms.  Please see the "DAC Addressing
-for Address Space Hungry Devices" setion near the end of this
+for Address Space Hungry Devices" section near the end of this
 document for how to handle this case.
 
 Finally, if your device can only drive the low 24-bits of
@@ -205,7 +205,7 @@
 
 - Consistent DMA mappings which are usually mapped at driver
   initialization, unmapped at the end and for which the hardware should
-  guarantee that the device and the cpu can access the data
+  guarantee that the device and the CPU can access the data
   in parallel and will see updates made by each other without any
   explicit software flushing.
 
@@ -222,12 +222,12 @@
 	- Device firmware microcode executed out of
 	  main memory.
 
-  The invariant these examples all require is that any cpu store
+  The invariant these examples all require is that any CPU store
   to memory is immediately visible to the device, and vice
   versa.  Consistent mappings guarantee this.
 
   IMPORTANT: Consistent DMA memory does not preclude the usage of
-             proper memory barriers.  The cpu may reorder stores to
+             proper memory barriers.  The CPU may reorder stores to
 	     consistent memory just as it may normal memory.  Example:
 	     if it is important for the device to see the first word
 	     of a descriptor updated before the second, you must do
@@ -284,7 +284,7 @@
 the pci_pool interface, described below.
 
 The consistent DMA mapping interfaces, for non-NULL dev, will always
-return a DMA address which is SAC (Single Address Cycle) addressible.
+return a DMA address which is SAC (Single Address Cycle) addressable.
 Even if the device indicates (via PCI dma mask) that it may address
 the upper 32-bits and thus perform DAC cycles, consistent allocation
 will still only return 32-bit PCI addresses for DMA.  This is true
@@ -484,7 +484,7 @@
 of sg entries it mapped them to.
 
 Then you should loop count times (note: this can be less than nents times)
-and use sg_dma_address() and sg_dma_length() macros where you previously
+and use sg_dma_address() and sg_dma_len() macros where you previously
 accessed sg->address and sg->length as shown above.
 
 To unmap a scatterlist, just call:
@@ -622,7 +622,7 @@
 Note that for streaming type mappings you must either use these
 interfaces, or the dynamic mapping interfaces above.  You may not mix
 usage of both for the same device.  Such an act is illegal and is
-guarenteed to put a banana in your tailpipe.
+guaranteed to put a banana in your tailpipe.
 
 However, consistent mappings may in fact be used in conjunction with
 these interfaces.  Remember that, as defined, consistent mappings are
@@ -637,7 +637,7 @@
 use the following interfaces if this routine fails.
 
 Next, DMA addresses using this API are kept track of using the
-dma64_addr_t type.  It is guarenteed to be big enough to hold any
+dma64_addr_t type.  It is guaranteed to be big enough to hold any
 DAC address the platform layer will give to you from the following
 routines.  If you have consistent mappings as well, you still
 use plain dma_addr_t to keep track of those.
@@ -745,7 +745,7 @@
 			 PCI_DMA_FROMDEVICE);
 
 It really should be self-explanatory.  We treat the ADDR and LEN
-seperately, because it is possible for an implementation to only
+separately, because it is possible for an implementation to only
 need the address in order to perform the unmap operation.
 
 			Platform Issues