On Sat, Jun 06, 2009 at 02:16:46PM +1000, Benjamin Herrenschmidt wrote: > 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. All good questions. So, let's ask the original authors :) Frank and Ian, any thoughts about the vmap call in the comedi_buf_alloc() call? Why is it using PAGE_KERNEL_NOCACHE, and what is the prealloc_buf buffer used for? The problem is that PAGE_KERNEL_NOCACHE isn't a "standard" interface, and not all architectures support it. thanks, greg k-h -- 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
