Re: [RFC] on-chip coherent memory API for DMA

[David Brownell <david-b@pacbell.net>]

James Bottomley wrote:
> On Thu, 2004-07-01 at 15:14, David Brownell wrote:
> 
>>That can work when the scope of "DMA" knowledge is just
>>one driver ... but when that driver is plugging into a
>>framework, it's as likely to be some other code (maybe
>>a higher level driver) that just wants RAM address space
>>which, for whatever reasons, is DMA-coherent.  And hey,
>>the way to get this is dma_alloc_coherent ... or in some
>>cases, pci_alloc_consistent.
> 
> 
> If the driver can't cope then you *only* use DMA_MEMORY_MAP

That would be the norm for all those low-level drivers,
certainly.  Except maybe on that one mysterious box,
where the CPU can't access that memory directly ... ;)


>>Which is why my comment was that the new feature of
>>returning some kind of memory cookie usable on that one
>>IBM box (etc) should just use a different allocator API.
>>It doesn't allocate RAM "similarly to __get_free_pages";
>>it'd be returning something drivers can't treat as RAM.
> 
> 
> Well, I don't believe it will be necessary.  However, when an actual
> user comes along, we'll find out.

OK, I can easily view DMA_MEMORY_IO as an API experiment.


> It is no-longer real memory once you use this API.  Even if the
> processor can treat DMA_MEMORY_MAP memory as "real", you'll probably
> find that a device off on another bus cannot even see it.  However, as
> long as you keep the memory between the processor and the device then
> you can treat it identical to RAM.

I'm not sure I see what you're saying.  The only guarantees on
the memory are that "the" CPU and the device can both access
it like memory.  Other devices are out-of-scope, as is location
(anywhere both can access it like normal memory, not just stuff
that's "between" the two on some bus).  It's DMA_MEMORY_IO that
you said would not be RAM-like ("directly writable"), and would
need I/O memory accessors like readl/writel/etc ... to the
device it looks like normal RAM, but not to the host.



> The intention of the flags option for dma_alloc_coherent() was only for
> memory allocation instructions; the allocation can fail for other
> reasons that unavailability of memory depending on how the API is
> implemented, so __GFP_NOFAIL doesn't actually work now in every case. 

I personally think __GFP_WAIT is the most important one, but
some folk have other priorities.  Regardless, I _was_ talking
about passing flags down to the memory allocator, so it sounds
like it was just an oversight in this initial version.

- Dave