- 24 8月, 2010 1 次提交
-
-
由 Anton Blanchard 提交于
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: NAnton Blanchard <anton@samba.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 24 7月, 2010 1 次提交
-
-
由 Grant Likely 提交于
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: NGrant Likely <grant.likely@secretlab.ca> Acked-by: NDavid S. Miller <davem@davemloft.net>
-
- 14 7月, 2010 1 次提交
-
-
由 Yinghai Lu 提交于
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: NIngo Molnar <mingo@elte.hu> Acked-by: N"H. Peter Anvin" <hpa@zytor.com> Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 02 6月, 2010 1 次提交
-
-
由 Denis Kirjanov 提交于
Fix smatch warning: warning: constant 0x800000000 is so big it is long Signed-off-by: NDenis Kirjanov <dkirjanov@kernel.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 19 5月, 2010 1 次提交
-
-
由 Grant Likely 提交于
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: NGrant Likely <grant.likely@secretlab.ca>
-
- 30 3月, 2010 1 次提交
-
-
由 Tejun Heo 提交于
include cleanup: Update gfp.h and slab.h includes to prepare for breaking 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: NTejun Heo <tj@kernel.org> Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
-
- 24 9月, 2009 1 次提交
-
-
由 Becky Bruce 提交于
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: NBecky Bruce <beckyb@kernel.crashing.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 28 8月, 2009 1 次提交
-
-
由 FUJITA Tomonori 提交于
This converts uses dma_map_ops struct (in include/linux/dma-mapping.h) instead of POWERPC homegrown dma_mapping_ops. Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by: NBecky Bruce <beckyb@kernel.crashing.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 15 6月, 2009 1 次提交
-
-
由 Geert Uytterhoeven 提交于
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: NGeert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 07 4月, 2009 1 次提交
-
-
由 Yang Hongyang 提交于
Replace all DMA_64BIT_MASK macro with DMA_BIT_MASK(64) Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 24 3月, 2009 1 次提交
-
-
由 Jeremy Kerr 提交于
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: NJeremy Kerr <jk@ozlabs.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 13 1月, 2009 1 次提交
-
-
由 Ingo Molnar 提交于
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: NIngo Molnar <mingo@elte.hu> Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 08 1月, 2009 1 次提交
-
-
由 Ingo Molnar 提交于
in/out_be64() work on u64s. The first parameter to ppc_md.ioremap is a phys_addr_t. Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 19 11月, 2008 1 次提交
-
-
由 Michael Ellerman 提交于
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 31 10月, 2008 1 次提交
-
-
由 Mark Nelson 提交于
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: NMark Nelson <markn@au1.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 25 9月, 2008 1 次提交
-
-
由 Becky Bruce 提交于
Use the struct device's numa_node instead; use accessor functions to get/set numa_node. Signed-off-by: NBecky Bruce <becky.bruce@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
- 25 7月, 2008 2 次提交
-
-
由 Robert Jennings 提交于
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: NRobert Jennings <rcj@linux.vnet.ibm.com> Acked-by: NOlof Johansson <olof@lixom.net> Acked-by: NPaul Mackerras <paulus@samba.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Mark Nelson 提交于
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: NMark Nelson <markn@au1.ibm.com> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 22 7月, 2008 2 次提交
-
-
由 Mark Nelson 提交于
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: NMark Nelson <markn@au1.ibm.com> Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Mark Nelson 提交于
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: NMark Nelson <markn@au1.ibm.com> Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 09 7月, 2008 1 次提交
-
-
由 Mark Nelson 提交于
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: NMark Nelson <markn@au1.ibm.com> Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 01 4月, 2008 1 次提交
-
-
由 Harvey Harrison 提交于
__FUNCTION__ is gcc-specific, use __func__ Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 20 3月, 2008 1 次提交
-
-
由 Michael Ellerman 提交于
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: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 03 3月, 2008 8 次提交
-
-
由 Michael Ellerman 提交于
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: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Michael Ellerman 提交于
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: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Michael Ellerman 提交于
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: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Michael Ellerman 提交于
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: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Michael Ellerman 提交于
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: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Michael Ellerman 提交于
The cell IOMMU code no longer needs to save the pte_offset variable separately, it is incorporated into tbl->it_offset. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Michael Ellerman 提交于
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: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Michael Ellerman 提交于
It's called the fixed mapping, not the static mapping. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
- 14 2月, 2008 1 次提交
-
-
由 David S. Miller 提交于
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 08 2月, 2008 4 次提交
-
-
由 Michael Ellerman 提交于
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: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Michael Ellerman 提交于
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: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Michael Ellerman 提交于
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: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Michael Ellerman 提交于
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: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 31 1月, 2008 4 次提交
-
-
由 Michael Ellerman 提交于
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: NMichael Ellerman <michael@ellerman.id.au> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Michael Ellerman 提交于
Split out the ioid fetching and checking logic so we can use it elsewhere in a subsequent patch. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Michael Ellerman 提交于
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: NMichael Ellerman <michael@ellerman.id.au> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Michael Ellerman 提交于
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: NMichael Ellerman <michael@ellerman.id.au> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-