Home Home > GIT Browse
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@penguin.transmeta.com>2002-03-11 21:33:11 -0800
committerLinus Torvalds <torvalds@penguin.transmeta.com>2002-03-11 21:33:11 -0800
commiteb86b60f8e6556bafc0ff4d8843bb6fcf57c8516 (patch)
tree0c6083e85d7686573f16576b5a02e3e757a31e20
parentd9f2d50eabbb92ceef65221933651fcfb728c800 (diff)
parentc1f66bf620063bbc02d26155210c8044476e5c7c (diff)
Merge master.kernel.org:/home/davem/BK/misc-2.5
into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux
-rw-r--r--Documentation/DMA-mapping.txt22
-rw-r--r--include/asm-i386/pgalloc.h2
-rw-r--r--mm/memory.c3
3 files changed, 16 insertions, 11 deletions
diff --git a/Documentation/DMA-mapping.txt b/Documentation/DMA-mapping.txt
index 6d2961c14d1c..1690b0ed0138 100644
--- a/Documentation/DMA-mapping.txt
+++ b/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 @@ returned from the DMA mapping functions.
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 @@ This means that in the failure case, you have three options:
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 @@ all 64-bits during a DAC cycle:
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 @@ There are two types of DMA mappings:
- 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 @@ There are two types of DMA mappings:
- 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 @@ driver needs regions sized smaller than a page, you may prefer using
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
@@ -622,7 +622,7 @@ use the normal APIs without any problems.
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 @@ This routine behaves identically to pci_set_dma_mask. You may not
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 @@ transform some example code.
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
diff --git a/include/asm-i386/pgalloc.h b/include/asm-i386/pgalloc.h
index cf81870ff17c..0af21645a1f1 100644
--- a/include/asm-i386/pgalloc.h
+++ b/include/asm-i386/pgalloc.h
@@ -223,4 +223,6 @@ static inline void flush_tlb_pgtables(struct mm_struct *mm,
/* i386 does not keep any page table caches in TLB */
}
+#define check_pgt_cache() do { } while (0)
+
#endif /* _I386_PGALLOC_H */
diff --git a/mm/memory.c b/mm/memory.c
index 3a7a1a7a72e5..34f125c8f043 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -140,6 +140,9 @@ void clear_page_tables(struct mm_struct *mm, unsigned long first, int nr)
page_dir++;
} while (--nr);
spin_unlock(&mm->page_table_lock);
+
+ /* keep the page table cache within bounds */
+ check_pgt_cache();
}
pte_t * pte_alloc_map(struct mm_struct *mm, pmd_t *pmd, unsigned long address)