patch-2.4.0-test6 linux/Documentation/DMA-mapping.txt

• Lines: 39
• Date: Fri Jul 28 12:50:51 2000
• Orig file: v2.4.0-test5/linux/Documentation/DMA-mapping.txt
• Orig date: Wed Apr 26 16:34:06 2000

diff -u --recursive --new-file v2.4.0-test5/linux/Documentation/DMA-mapping.txt linux/Documentation/DMA-mapping.txt
@@ -111,7 +111,7 @@
 
 - Consistent DMA mappings which are usually mapped at driver
   initialization, unmapped at the end and for which the hardware should
-  guarentee 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.
 
@@ -126,7 +126,7 @@
 
   The invariant these examples all require is that any cpu store
   to memory is immediately visible to the device, and vice
-  versa.  Consistent mappings guarentee this.
+  versa.  Consistent mappings guarantee this.
 
 - Streaming DMA mappings which are usually mapped for one DMA transfer,
   unmapped right after it (unless you use pci_dma_sync below) and for which
@@ -171,9 +171,9 @@
 The cpu return address and the DMA bus master address are both
 guaranteed to be aligned to the smallest PAGE_SIZE order which
 is greater than or equal to the requested size.  This invariant
-exists (for example) to guarentee that if you allocate a chunk
+exists (for example) to guarantee that if you allocate a chunk
 which is smaller than or equal to 64 kilobytes, the extent of the
-buffer you receive will not cross a 64K boundry.
+buffer you receive will not cross a 64K boundary.
 
 To unmap and free such a DMA region, you call:
 
@@ -203,7 +203,7 @@
 
 If you absolutely cannot know the direction of the DMA transfer,
 specify PCI_DMA_BIDIRECTIONAL.  It means that the DMA can go in
-either direction.  The platform guarentees that you may legally
+either direction.  The platform guarantees that you may legally
 specify this, and that it will work, but this may be at the
 cost of performance for example.