summaryrefslogtreecommitdiffstats
path: root/arch/ppc64/kernel/vdso64
diff options
context:
space:
mode:
authorArnd Bergmann <arnd@arndb.de>2005-06-23 09:43:54 +1000
committerPaul Mackerras <paulus@samba.org>2005-06-23 09:43:54 +1000
commitae209cf10086b97e92e39af7cec0f84b21b6fca3 (patch)
tree9373d6ce5baef7e3d1d65e3fb21c5d0bbcbeec15 /arch/ppc64/kernel/vdso64
parentcebf589c822b5de87098b57644024d16f8dbc1bb (diff)
downloadtalos-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
OpenPOWER on IntegriCloud