diff options
author | Arnd Bergmann <arnd@arndb.de> | 2005-06-23 09:43:54 +1000 |
---|---|---|
committer | Paul Mackerras <paulus@samba.org> | 2005-06-23 09:43:54 +1000 |
commit | ae209cf10086b97e92e39af7cec0f84b21b6fca3 (patch) | |
tree | 9373d6ce5baef7e3d1d65e3fb21c5d0bbcbeec15 /arch/ppc64/kernel/vdso64 | |
parent | cebf589c822b5de87098b57644024d16f8dbc1bb (diff) | |
download | talos-op-linux-ae209cf10086b97e92e39af7cec0f84b21b6fca3.tar.gz talos-op-linux-ae209cf10086b97e92e39af7cec0f84b21b6fca3.zip |
[PATCH] ppc64: Add driver for BPA iommu
Implementation of software load support for the BE iommu. This is very
different from other iommu code on ppc64, since we only do a static mapping.
The mapping is currently hardcoded but should really be read from the
firmware, but they don't set up the device nodes yet. There is a single
512MB DMA window for PCI, USB and ethernet at 0x20000000 for our RAM.
The Cell processor can put the I/O page table either in memory like
the hashed page table (hardware load) or have the operating system
write the entries into memory mapped CPU registers (software load).
I use the software load mechanism because I know that all I/O page
table entries for the amount of installed physical memory fit into
the IO TLB cache. At the point when we get machines with more than
4GB of installed memory, we can either use hardware I/O page table
access like the other platforms do or dynamically update the I/O
TLB entries when a page fault occurs in the I/O subsystem.
The software load can then use the macros that I have implemented
for the static mapping in order to do the TLB cache updates.
Signed-off-by: Arnd Bergmann <arndb@de.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Diffstat (limited to 'arch/ppc64/kernel/vdso64')
0 files changed, 0 insertions, 0 deletions