Messages in this thread | | | Date | Thu, 24 Jun 2004 13:13:47 +0200 | From | Takashi Iwai <> | Subject | Re: 32-bit dma allocations on 64-bit platforms |
| |
At 24 Jun 2004 01:46:44 +0200, Andi Kleen wrote: > > > > I must say I'm somewhat reluctant to break an working in tree driver. > > > Especially for the sake of an out of tree binary driver. Arguably the > > > problem is probably not limited to you, but it's quite possible that > > > even the in tree DRI drivers have it, so it would be still worth to > > > fix it. > > > > agreed. I completely understand that there is no desire to modify the > > core kernel to help our driver. that's one of the reasons I looked through > > the other drivers, as I suspect that this is a problem for many drivers. I > > only looked through the code for each briefly, but didn't see anything to > > handle this. I suspect it's more of a case that the drivers have not been > > stress tested on an x86_64 machine w/ 4+ G of memory. > > We usually handle it using the swiotlb, which works. > > pci_alloc_consistent is limited to 16MB, but so far nobody has really > complained about that. If that should be a real issue we can make > it allocate from the swiotlb pool, which is usually 64MB (and can > be made bigger at boot time)
Can't it be called with GFP_KERNEL at first, then with GFP_DMA if the allocated pages are out of dma mask, just like in pci-gart.c? (with ifdef x86-64)
Takashi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |