It might explain why my machine hung when I tried to use radeon with DRM on my sparc64 workstation :-) I have investigating that on my todo list.
True, maybe the intersection is me + hw like that + radeon :-)
I don't know what to recommend to you, getting 8MB of linear memory really just isn't practical.
This is the thing it doesn't need to be linear, I have a GART onboard the radeon that I can fill in, I just need internally in the kernel to access it linearly and in userspace to map it linearly, but it doesn't need to be physcially linear, vmalloc_32 + map_single should in theory be possible if.. see below...
Perhaps we'll have to create something ugly like vmalloc_nobounce(). Remind me again why you're ending up with swiotlb'd pages? vmalloc_32() uses GFP_KERNEL which should use entirely lowmem and thus RAM below 4GB and not anything which should need bounce buffering.
On a 64-bit machine GFP_KERNEL can give me any memory... it all works fine on 32-bit highmem kernel as I don't get highmem... I really need __GFP_DMA32 memory but we don't have a generic allocator that gives this out that I can see..
Are you expecting to be able to virtually remap these pages in PCI space as one huge 8MB chunk too and that's how swiotlb gets involved? That won't work, sorry...
Well I feed the bus address for each page into a GART table in the GPU and it does the linear stuff internally in the GPU memory controller... I suppose I want __GFP_I_D_RATHER_DIE_THAN_BOUNCE. Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
