On Fri, 2009-06-05 at 17:56 -0700, David Miller wrote: > > > > Read my reply to Greg. Why the heck are you trying to map memory > > non-cacheable in the first place ? > > I agree, this is extremely fishy. > > I guess the issue is that the driver wants consistent DMA memory > but wants to allocate a huge area vmap() style. That's my guess too, and I suppose we should be able to provide an appropriate interface for that... There are two aspects that are completely separate here: - One is the allocation of the pages themselves which much match the various criteria for DMA'bility to the target device (fit the DMA mask, etc...) - One is the creation of the virtual mapping in kernel space for which appropriate pgprot for DMA must be provided. For the first one, I don't know how legit it would be to allocate the pages using dma_alloc_coherent one page at a time and try to figure out the struct page * out of it. Sounds fishy and possibly non-portable. So appart from using normal GFP and crossing fingers I'm not sure what would be the right way to obtain the pages in the first place. Maybe we should provide something. The second could be as simple as having a pgprot_dma_coherent() like we have a pgprot_uncached() for example, which would be either uncached or cached depending on the consistency of DMA on the platform. But we need to run that through things like MIPS which may have additional virtual address space requirements. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
