- 19 Apr, 2008 40 commits
-
-
Glauber Costa authored
They are placed in an ifdef, since they are i386 specific the structure definition goes to dma-mapping.h. Signed-off-by:
Glauber Costa <gcosta@redhat.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Glauber Costa authored
we merge the iommu initialization parameters in pci-dma.c Nice thing, that both architectures at least recognize the same parameters. usedac i386 parameter is marked for deprecation Signed-off-by:
-
Glauber Costa authored
The code for both arches are very similar, so this patch merge them. Signed-off-by:
-
Glauber Costa authored
via_no_dac provides a fixup that is the same for both architectures. Move it to pci-dma.c. Signed-off-by:
-
Glauber Costa authored
This patch moves the bootmem functions, that are largely x86_64-specific into pci-dma.c. The code goes inside an ifdef. Signed-off-by:
-
Glauber Costa authored
initcalls that triggers the various possibiities for dma subsys are moved to pci-dma.c. Signed-off-by:
-
Glauber Costa authored
merge pci-base_32.c and pci-nommu_64.c into pci-nommu.c Their code were made the same, so now they can be merged. Signed-off-by:
-
Glauber Costa authored
Move dma_ops structure definition to pci-dma.c, where it belongs. Signed-off-by:
-
Glauber Costa authored
This is done to get the code closer to x86_64. Signed-off-by:
-
Glauber Costa authored
In the very same way i386 do, we use WARN_ON functions in map_simple and map_sg. Signed-off-by:
-
Glauber Costa authored
To make the code usable in i386, where we have high memory mappings, we drop te virt_to_bus(sg_virt()) construction in favour of sg_phys. Signed-off-by:
-
Glauber Costa authored
This patch adds flush_write_buffers() in some functions of pci-nommu_64.c They are added anywhere i386 would also have it. This is not a problem for x86_64, since flush_rite_buffers() an nop for it. Signed-off-by:
-
Glauber Costa authored
This patch implements mapping_error for pci-nommu_64.c. It takes care to keep the same compatible behaviour it already had. Although this file is not (yet) used for i386, we introduce the i386 version here. Again, care is taken, even at the expense of an ifdef, to keep the same behaviour inconditionally. Signed-off-by:
-
Glauber Costa authored
This functions are now called conditionally on their existence in the struct. So just delete them, instead of keeping an empty implementation. Signed-off-by:
-
Glauber Costa authored
This patch introduces pci-dma.c, a common file for pci dma between i386 and x86_64. As a start, dma_set_mask() is the same between architectures, and is placed there. Signed-off-by:
-
Mark McLoughlin authored
ERROR: "dma_supported" [drivers/ssb/ssb.ko] undefined! ERROR: "dma_set_mask" [drivers/scsi/qla2xxx/qla2xxx.ko] undefined! ERROR: "dma_set_mask" [drivers/scsi/aic7xxx/aic7xxx.ko] undefined! ERROR: "dma_set_mask" [drivers/scsi/aic7xxx/aic79xx.ko] undefined! ERROR: "dma_supported" [drivers/net/pcnet32.ko] undefined! ERROR: "dma_supported" [drivers/media/video/saa7134/saa7134.ko] undefined! ERROR: "dma_set_mask" [drivers/media/video/meye.ko] undefined! ERROR: "dma_supported" [drivers/media/video/cx88/cx8802.ko] undefined! ERROR: "dma_supported" [drivers/media/video/cx88/cx8800.ko] undefined! ERROR: "dma_supported" [drivers/media/video/cx88/cx88-alsa.ko] undefined! ERROR: "dma_supported" [drivers/media/video/cx23885/cx23885.ko] undefined! They just need to be exported like on x86_64. dma_supported() and dma_set_mask() were previously inlined, but are now moved to pci-dma_32.c. Since they're used by various drivers, they need to be exported. Signed-off-by:
Mark McLoughlin <markmc@redhat.com> Signed-off-by:
-
Glauber Costa authored
all the code that is left is ready to be merged as-is in dma-mapping.h. Signed-off-by:
-
Glauber Costa authored
define it conditionally to i386. Signed-off-by:
-
Glauber Costa authored
We provide a map_error function in pci-base_32.c to make sure i386 keeps with the same behaviour it used to. Signed-off-by:
-
Glauber Costa authored
It's initially 0, since we don't expect any DMA there. Signed-off-by:
-
Glauber Costa authored
Do it instead of using the conservative approach we're currently doing. This is the way x86_64 does, and this patch makes this piece of code the same between them, ready to be integrated. Signed-off-by:
-
Glauber Costa authored
This is the way x86_64 does, so this make them equal. They have to be extern now in the header, and the extern definition is moved to the common dma-mapping.h header. Signed-off-by:
-
Glauber Costa authored
they are the same in both architectures. Signed-off-by:
-
Ingo Molnar authored
Signed-off-by:
-
Glauber Costa authored
They are similar enough to do this move. the macro version is ugly, and we use inline functions instead. Signed-off-by:
-
Glauber Costa authored
they are the same between architectures. (except for the fact that x86_64 has duplicate code) move them to dma-mapping.h Signed-off-by:
-
Glauber Costa authored
i386 gets an empty function. Signed-off-by:
-
Glauber Costa authored
i386 gets an empty function. Signed-off-by:
-
Glauber Costa authored
i386 gets an empty function. Signed-off-by:
-
Glauber Costa authored
i386 gets an empty function. Signed-off-by:
-
Glauber Costa authored
i386 gets an empty function. Signed-off-by:
-
Glauber Costa authored
i386 gets an empty function. Signed-off-by:
-
Glauber Costa authored
i386 gets an empty function. Signed-off-by:
-
Glauber Costa authored
the old i386 implementation is moved to pci-base_32.c Signed-off-by:
-
Glauber Costa authored
i386 base does not need it, so it gets an empty function. Signed-off-by:
-
Glauber Costa authored
That's already the name of the game for x86_64. For i386, we add a pci-base_32.c, that will hold the default operations. The function call itself goes through dma-mapping.h , the common header Signed-off-by:
-
Glauber Costa authored
take it off the x86_64 specific header Signed-off-by:
-
Yinghai Lu authored
a system with 256 GB of RAM, when NUMA is disabled crashes the following way: Your BIOS doesn't leave a aperture memory hole Please enable the IOMMU option in the BIOS setup This costs you 64 MB of RAM Cannot allocate aperture memory hole (ffff8101c0000000,65536K) Kernel panic - not syncing: Not enough memory for aperture Pid: 0, comm: swapper Not tainted 2.6.25-rc4-x86-latest.git #33 Call Trace: [<ffffffff84037c62>] panic+0xb2/0x190 [<ffffffff840381fc>] ? release_console_sem+0x7c/0x250 [<ffffffff847b1628>] ? __alloc_bootmem_nopanic+0x48/0x90 [<ffffffff847b0ac9>] ? free_bootmem+0x29/0x50 [<ffffffff847ac1f7>] gart_iommu_hole_init+0x5e7/0x680 [<ffffffff847b255b>] ? alloc_large_system_hash+0x16b/0x310 [<ffffffff84506a2f>] ? _etext+0x0/0x1 [<ffffffff847a2e8c>] pci_iommu_alloc+0x1c/0x40 [<ffffffff847ac795>] mem_init+0x45/0x1a0 [<ffffffff8479ff35>] start_kernel+0x295/0x380 [<ffffffff8479f1c2>] _sinittext+0x1c2/0x230 the root cause is : memmap PMD is too big, [ffffe200e0600000-ffffe200e07fffff] PMD ->ffff81383c000000 on node 0 almost near 4G..., and vmemmap_alloc_block will use up the ram under 4G. solution will be: 1. make memmap allocation get memory above 4G... 2. reserve some dma32 range early before we try to set up memmap for all. and release that before pci_iommu_alloc, so gart or swiotlb could get some range under 4g limit for sure. the patch is using method 2. because method1 may need more code to handle SPARSEMEM and SPASEMEM_VMEMMAP will get Your BIOS doesn't leave a aperture memory hole Please enable the IOMMU option in the BIOS setup This costs you 64 MB of RAM Mapping aperture over 65536 KB of RAM @ 4000000 Memory: 264245736k/268959744k available (8484k kernel code, 4187464k reserved, 4004k data, 724k init) Signed-off-by:
Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by:
-
Suresh Siddha authored
For example, If the physical address layout on a two node system with 8 GB memory is something like: node 0: 0-2GB, 4-6GB node 1: 2-4GB, 6-8GB Current kernels fail to boot/detect this NUMA topology. ACPI SRAT tables can expose such a topology which needs to be supported. Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by:
-
Roland McGrath authored
The 64-bit vDSO's sources are compiled with -g0 for no good reason. Using -g when enabled lets their separate debug files be used at runtime via build ID matching, same as we can see 32-bit vDSO's assembly sources. Signed-off-by:
Roland McGrath <roland@redhat.com> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
