summaryrefslogtreecommitdiffstats
path: root/arch/powerpc/platforms/cell/iommu.c
Commit message (Collapse)AuthorAgeFilesLines
* powerpc: Fix bogus it_blocksize in VIO iommu codeAnton Blanchard2010-08-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When looking at some issues with the virtual ethernet driver I noticed that TCE allocation was following a very strange pattern: address 00e9000 length 2048 address 0409000 length 2048 <----- address 0429000 length 2048 address 0449000 length 2048 address 0469000 length 2048 address 0489000 length 2048 address 04a9000 length 2048 address 04c9000 length 2048 address 04e9000 length 2048 address 4009000 length 2048 <----- address 4029000 length 2048 Huge unexplained gaps in what should be an empty TCE table. It turns out it_blocksize, the amount we want to align the next allocation to, was c0000000fe903b20. Completely bogus. Initialise it to something reasonable in the VIO IOMMU code, and use kzalloc everywhere to protect against this when we next add a non compulsary field to iommu code and forget to initialise it. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* of: Merge of_platform_bus_type with platform_bus_typeGrant Likely2010-07-241-1/+1
| | | | | | | | | | | | | | | | | | | | of_platform_bus was being used in the same manner as the platform_bus. The only difference being that of_platform_bus devices are generated from data in the device tree, and platform_bus devices are usually statically allocated in platform code. Having them separate causes the problem of device drivers having to be registered twice if it was possible for the same device to appear on either bus. This patch removes of_platform_bus_type and registers all of_platform bus devices and drivers on the platform bus instead. A previous patch made the of_device structure an alias for the platform_device structure, and a shim is used to adapt of_platform_drivers to the platform bus. After all of of_platform_bus drivers are converted to be normal platform drivers, the shim code can be removed. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: David S. Miller <davem@davemloft.net>
* lmb: rename to memblockYinghai Lu2010-07-141-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | via following scripts FILES=$(find * -type f | grep -vE 'oprofile|[^K]config') sed -i \ -e 's/lmb/memblock/g' \ -e 's/LMB/MEMBLOCK/g' \ $FILES for N in $(find . -name lmb.[ch]); do M=$(echo $N | sed 's/lmb/memblock/g') mv $N $M done and remove some wrong change like lmbench and dlmb etc. also move memblock.c from lib/ to mm/ Suggested-by: Ingo Molnar <mingo@elte.hu> Acked-by: "H. Peter Anvin" <hpa@zytor.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* powerpc/cell: Fix integer constant warningDenis Kirjanov2010-06-021-1/+1
| | | | | | | Fix smatch warning: warning: constant 0x800000000 is so big it is long Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* of: eliminate of_device->node and dev_archdata->{of,prom}_nodeGrant Likely2010-05-181-3/+2
| | | | | | | | | | | | | This patch eliminates the node pointer from struct of_device and the of_node (or prom_node) pointer from struct dev_archdata since the node pointer is now part of struct device proper when CONFIG_OF is set, and all users of the old pointer locations have already been converted over to use device->of_node. Also remove dev_archdata_{get,set}_node() as it is no longer used by anything. Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo2010-03-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
* powerpc: Change archdata dma_data to a unionBecky Bruce2009-09-241-6/+3
| | | | | | | | | | Sometimes this is used to hold a simple offset, and sometimes it is used to hold a pointer. This patch changes it to a union containing void * and dma_addr_t. get/set accessors are also provided, because it was getting a bit ugly to get to the actual data. Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* powerpc: use dma_map_ops structFUJITA Tomonori2009-08-281-1/+1
| | | | | | | | | This converts uses dma_map_ops struct (in include/linux/dma-mapping.h) instead of POWERPC homegrown dma_mapping_ops. Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by: Becky Bruce <beckyb@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* powerpc/cell: Extract duplicated IOPTE_* to <asm/iommu.h>Geert Uytterhoeven2009-06-151-22/+15
| | | | | | | | | | Both arch/powerpc/platforms/cell/iommu.c and arch/powerpc/platforms/ps3/mm.c contain the same Cell IOMMU page table entry definitions. Extract them and move them to <asm/iommu.h>, while adding a CBE_ prefix. This also allows them to be used by drivers. Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* dma-mapping: replace all DMA_64BIT_MASK macro with DMA_BIT_MASK(64)Yang Hongyang2009-04-071-1/+1
| | | | | | | | Replace all DMA_64BIT_MASK macro with DMA_BIT_MASK(64) Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* powerpc/cell: Fix iommu exception reportingJeremy Kerr2009-03-241-4/+5
| | | | | | | | | | | Currently, we will report a page fault as a segment fault, and report a segment fault as both a page and segment fault. Fix the SPF_P definition to be correct according to the iommu docs, and mask before comparing. Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* powerpc: Change u64/s64 to a long long integer typeIngo Molnar2009-01-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | Convert arch/powerpc/ over to long long based u64: -#ifdef __powerpc64__ -# include <asm-generic/int-l64.h> -#else -# include <asm-generic/int-ll64.h> -#endif +#include <asm-generic/int-ll64.h> This will avoid reoccuring spurious warnings in core kernel code that comes when people test on their own hardware. (i.e. x86 in ~98% of the cases) This is what x86 uses and it generally helps keep 64-bit code 32-bit clean too. [Adjusted to not impact user mode (from paulus) - sfr] Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* powerpc/cell: Fix some u64 vs. long typesIngo Molnar2009-01-081-2/+2
| | | | | | | | | | | in/out_be64() work on u64s. The first parameter to ppc_md.ioremap is a phys_addr_t. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* powerpc: Use of_find_node_with_property() in cell_iommu_fixed_mapping_init()Michael Ellerman2008-11-191-4/+1
| | | | | Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
* powerpc: Update remaining dma_mapping_ops to use map/unmap_pageMark Nelson2008-10-311-19/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After the merge of the 32 and 64bit DMA code, dma_direct_ops lost their map/unmap_single() functions but gained map/unmap_page(). This caused a problem for Cell because Cell's dma_iommu_fixed_ops called the dma_direct_ops if the fixed linear mapping was to be used or the iommu ops if the dynamic window was to be used. So in order to fix this problem we need to update the 64bit DMA code to use map/unmap_page. First, we update the generic IOMMU code so that iommu_map_single() becomes iommu_map_page() and iommu_unmap_single() becomes iommu_unmap_page(). Then we propagate these changes up through all the callers of these two functions and in the process update all the dma_mapping_ops so that they have map/unmap_page rahter than map/unmap_single. We can do this because on 64bit there is no HIGHMEM memory so map/unmap_page ends up performing exactly the same function as map/unmap_single, just taking different arguments. This has no affect on drivers because the dma_map_single_attrs() just ends up calling the map_page() function of the appropriate dma_mapping_ops and similarly the dma_unmap_single_attrs() calls unmap_page(). This fixes an oops on Cell blades, which oops on boot without this because they call dma_direct_ops.map_single, which is NULL. Signed-off-by: Mark Nelson <markn@au1.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
* powerpc: Drop archdata numa_nodeBecky Bruce2008-09-241-3/+3
| | | | | | | | Use the struct device's numa_node instead; use accessor functions to get/set numa_node. Signed-off-by: Becky Bruce <becky.bruce@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
* powerpc/pseries: iommu enablement for CMORobert Jennings2008-07-251-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | To support Cooperative Memory Overcommitment (CMO), we need to check for failure from some of the tce hcalls. These changes for the pseries platform affect the powerpc architecture; patches for the other affected platforms are included in this patch. pSeries platform IOMMU code changes: * platform TCE functions must handle H_NOT_ENOUGH_RESOURCES errors and return an error. Architecture IOMMU code changes: * Calls to ppc_md.tce_build need to check return values and return DMA_MAPPING_ERROR for transient errors. Architecture changes: * struct machdep_calls for tce_build*_pSeriesLP functions need to change to indicate failure. * all other platforms will need updates to iommu functions to match the new calling semantics; they will return 0 on success. The other platforms default configs have been built, but no further testing was performed. Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com> Acked-by: Olof Johansson <olof@lixom.net> Acked-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* powerpc/cell: Fixed IOMMU mapping uses weak ordering for a pcie endpointMark Nelson2008-07-251-1/+12
| | | | | | | | | | | | | | | | At the moment the fixed mapping is by default strongly ordered (the iommu_fixed=weak boot option must be used to make the fixed mapping weakly ordered). If we're on a setup where the southbridge is being used in endpoint mode (triblade and CAB boards) the default should be a weakly ordered fixed mapping. This adds a check so that if a node of type pcie-endpoint can be found in the device tree the fixed mapping is set to be weak by default (but can be overridden using iommu_fixed=strong). Signed-off-by: Mark Nelson <markn@au1.ibm.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* powerpc/cell: Add DMA_ATTR_WEAK_ORDERING dma attribute and use in Cell IOMMU ↵Mark Nelson2008-07-221-5/+108
| | | | | | | | | | | | | | | | | code Introduce a new dma attriblue DMA_ATTR_WEAK_ORDERING to use weak ordering on DMA mappings in the Cell processor. Add the code to the Cell's IOMMU implementation to use this code. Dynamic mappings can be weakly or strongly ordered on an individual basis but the fixed mapping has to be either completely strong or completely weak. This is currently decided by a kernel boot option (pass iommu_fixed=weak for a weakly ordered fixed linear mapping, strongly ordered is the default). Signed-off-by: Mark Nelson <markn@au1.ibm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* powerpc/dma: Use the struct dma_attrs in iommu codeMark Nelson2008-07-221-2/+3
| | | | | | | | | | Update iommu_alloc() to take the struct dma_attrs and pass them on to tce_build(). This change propagates down to the tce_build functions of all the platforms. Signed-off-by: Mark Nelson <markn@au1.ibm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* powerpc/cell: cell_dma_dev_setup_iommu() return the iommu tableMark Nelson2008-07-091-4/+4
| | | | | | | | | | | | | | Make cell_dma_dev_setup_iommu() return a pointer to the struct iommu_table (or NULL if no table can be found) rather than putting this pointer into dev->archdata.dma_data (let the caller do that), and rename this function to cell_get_iommu_table() to reflect this change. This will allow us to get the iommu table for a device that doesn't have the table in the archdata. Signed-off-by: Mark Nelson <markn@au1.ibm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* [POWERPC] Replace remaining __FUNCTION__ occurrencesHarvey Harrison2008-04-011-4/+4
| | | | | | | | | __FUNCTION__ is gcc-specific, use __func__ Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
* Merge branch 'linux-2.6'Paul Mackerras2008-03-261-16/+25
|\
| * [POWERPC] Fix cell IOMMU code to cope with empty dma-ranges and non-PCI devicesMichael Ellerman2008-03-201-16/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The cell IOMMU code to parse the dma-ranges properties, used for the fixed mapping, was broken in two ways for some devices. Firstly it didn't cope with empty dma-ranges properties. An empty property implies no translation so can be safely skipped. The code also wrongly assumed it would be looking at PCI devices, and hard coded the number of address and size cells. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
* | Merge branch 'linux-2.6'Paul Mackerras2008-03-131-63/+88
|\ \ | |/
| * [POWERPC] Convert the cell IOMMU fixed mapping to 16M IOMMU pagesMichael Ellerman2008-03-031-15/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The only tricky part is we need to adjust the PTE insertion loop to cater for holes in the page table. The PTEs for each segment start on a 4K boundary, so with 16M pages we have 16 PTEs per segment and then a gap to the next 4K page boundary. It might be possible to allocate the PTEs for each segment separately, saving the memory currently filling the gaps. However we'd need to check that's OK with the hardware, and that it actually saves memory. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| * [POWERPC] Allow for different IOMMU page sizes in cell IOMMU codeMichael Ellerman2008-03-031-13/+18
| | | | | | | | | | | | | | | | Make some preliminary changes to cell_iommu_alloc_ptab() to allow it to take the page size as a parameter rather than assuming IOMMU_PAGE_SIZE. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| * [POWERPC] Cell IOMMU: n_pte_pages is in 4K page units, not IOMMU_PAGE_SIZEMichael Ellerman2008-03-031-5/+4
| | | | | | | | | | | | | | | | | | | | We use n_pte_pages to calculate the stride through the page tables, but we also use it to set the NPPT value in the segment table entry. That is defined as the number of 4K pages per segment, so we should calculate it as such regardless of the IOMMU page size. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| * [POWERPC] Split setup of IOMMU stab and ptab, allocate dynamic/fixed ptabs ↵Michael Ellerman2008-03-031-26/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | separately Currently the cell IOMMU code allocates the entire IOMMU page table in a contiguous chunk. This is nice and tidy, but for machines with larger amounts of RAM the page table allocation can fail due to it simply being too large. So split the segment table and page table setup routine, and arrange to have the dynamic and fixed page tables allocated separately. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| * [POWERPC] Move allocation of cell IOMMU pad pageMichael Ellerman2008-03-031-6/+6
| | | | | | | | | | | | | | | | There's no need to allocate the pad page unless we're going to actually use it - so move the allocation to where we know we're going to use it. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| * [POWERPC] Remove unused pte_offset variableMichael Ellerman2008-03-031-4/+1
| | | | | | | | | | | | | | | | The cell IOMMU code no longer needs to save the pte_offset variable separately, it is incorporated into tbl->it_offset. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| * [POWERPC] Use it_offset not pte_offset in cell IOMMU codeMichael Ellerman2008-03-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The cell IOMMU tce build and free routines use pte_offset to convert the index passed from the generic IOMMU code into a page table offset. This takes into account the SPIDER_DMA_OFFSET which sets the top bit of every DMA address. However it doesn't cater for the IOMMU window starting at a non-zero address, as the base of the window is not incorporated into pte_offset at all. As it turns out tbl->it_offset already contains the value we need, it takes into account the base of the window and also pte_offset. So use it instead! Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| * [POWERPC] Clearup cell IOMMU fixed mapping terminologyMichael Ellerman2008-03-031-4/+4
| | | | | | | | | | | | | | It's called the fixed mapping, not the static mapping. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* | [LIB]: Make PowerPC LMB code generic so sparc64 can use it too.David S. Miller2008-02-131-1/+1
|/ | | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [POWERPC] Make cell IOMMU fixed mapping printk more usefulMichael Ellerman2008-02-081-4/+2
| | | | | | | | | Currently the cell IOMMU fixed mapping just printks that it's been setup, which is not particularly useful. Much more interesting is the address ranges for the different windows. This adds one line to dmesg on a blade. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
* [POWERPC] Fix potential cell IOMMU bug when switching back to default DMA opsMichael Ellerman2008-02-081-8/+7
| | | | | | | | | | If we get a 64-bit dma mask we switch to the fixed ops and call cell_dma_dev_setup(). If the driver then switches back to a 32-bit dma mask for any reason we don't call cell_dma_dev_setup() again, which has the potential to leave bogus data in dev->archdata.dma_data. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
* [POWERPC] Don't enable cell IOMMU fixed mapping if there are no dma-rangesMichael Ellerman2008-02-081-0/+12
| | | | | | | | | In order for the cell IOMMU fixed mapping to work we need "dma-ranges" properties in the device tree. If there are none then there's no point enabling the fixed mapping support. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
* [POWERPC] Fix cell IOMMU null pointer explosion on old firmwaresMichael Ellerman2008-02-081-8/+7
| | | | | | | | | The cell IOMMU fixed mapping support has a null pointer bug if you run it on older firmwares that don't contain the "dma-ranges" properties. Fix it and convert to using of_get_next_parent() while we're there. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
* [POWERPC] Cell IOMMU fixed mapping supportMichael Ellerman2008-01-311-2/+267
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for setting up a fixed IOMMU mapping on certain cell machines. For 64-bit devices this avoids the performance overhead of mapping and unmapping pages at runtime. 32-bit devices are unable to use the fixed mapping. The fixed mapping is established at boot, and maps all of physical memory 1:1 into device space at some offset. On machines with < 30 GB of memory we setup the fixed mapping immediately above the normal IOMMU window. For example a machine with 4GB of memory would end up with the normal IOMMU window from 0-2GB and the fixed mapping window from 2GB to 6GB. In this case a 64-bit device wishing to DMA to 1GB would be told to DMA to 3GB, plus any offset required by firmware. The firmware offset is encoded in the "dma-ranges" property. On machines with 30GB or more of memory, we are unable to place the fixed mapping above the normal IOMMU window as we would run out of address space. Instead we move the normal IOMMU window to coincide with the hash page table, this region does not need to be part of the fixed mapping as no device should ever be DMA'ing to it. We then setup the fixed mapping from 0 to 32GB. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
* [POWERPC] Split out the ioid fetching/checking logicMichael Ellerman2008-01-311-6/+17
| | | | | | | | | Split out the ioid fetching and checking logic so we can use it elsewhere in a subsequent patch. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
* [POWERPC] Add support to cell_iommu_setup_page_tables() for multiple windowsMichael Ellerman2008-01-311-5/+10
| | | | | | | | | | | | | Add support to cell_iommu_setup_page_tables() for handling two windows, the dynamic window and the fixed window. A fixed window size of 0 indicates that there is no fixed window at all. Currently there are no callers who pass a non-zero fixed window, but the upcoming fixed IOMMU mapping patch will change that. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
* [POWERPC] Split out the IOMMU logic from cell_dma_dev_setup()Michael Ellerman2008-01-311-6/+13
| | | | | | | | | | Split the IOMMU logic out from cell_dma_dev_setup() into a separate function. If we're not using dma_direct_ops or dma_iommu_ops we don't know what the hell's going on, so BUG. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
* [POWERPC] Split cell_iommu_setup_hardware() into two partsMichael Ellerman2008-01-311-12/+26
| | | | | | | | | | Split cell_iommu_setup_hardware() into two parts. Split the page table setup into cell_iommu_setup_page_tables() and the bits that kick the hardware into cell_iommu_enable_hardware(). Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
* [POWERPC] Split out the logic that allocates struct iommusMichael Ellerman2008-01-311-4/+16
| | | | | | | | | | Split out the logic that allocates a struct iommu into a separate function. This can fail however the calling code has never cared - so just return if we can't allocate an iommu. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
* [POWERPC] Make IOMMU code safe for > 132 GB of memoryMichael Ellerman2008-01-251-3/+4
| | | | | | | | | Currently the IOMMU code allocates one page for the segment table, that isn't safe if we have more than 132 GB of RAM. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Acked-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
* [POWERPC] Have cell use its own dma_direct_offset variableMichael Ellerman2008-01-251-5/+7
| | | | | | | | | Rather than using the global variable, have cell use its own variable to store the direct DMA offset. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
* [POWERPC] Set archdata.dma_data for direct DMA in cell_dma_dev_setup()Michael Ellerman2008-01-251-2/+6
| | | | | | | | | | | | Store the direct_dma_offset in each device's dma_data in the case where we're using the direct DMA ops. We need to make sure we setup the ppc_md.pci_dma_dev_setup() callback if we're using a non-zero offset. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
* [POWERPC] cell: Use machine_*_initcall() hooks in platform codeGrant Likely2008-01-171-5/+2
| | | | | | Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
* [POWERPC] celleb: Split machine definitionIshizaki Kou2007-12-201-2/+2
| | | | | | | | | | | This splits the machine definition for celleb into two definitions, one for celleb_beat, and the other for celleb_native. Though this looks complex because of sorting some functions, there are no more semantic changes than that for the splitting. Signed-off-by: Kou Ishizaki <Kou.Ishizaki@toshiba.co.jp> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
* [POWERPC] cell: Convert #include of asm/of_{platform, device}.h into ↵Jon Loeliger2007-12-191-1/+1
| | | | | | | | linux/of_{platform, device}.h. Signed-off-by: Jon Loeliger <jdl@freescale.com> Acked-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
OpenPOWER on IntegriCloud