Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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.