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

[James Bottomley <James.Bottomley@steeleye.com>]

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_MAPPED.

> 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.

> This isn't I/O address space, needing PIO I/O accessors,
> and as returned by the new DMA_MEMORY_IO mode.  (And why
> wouldn't ioremap already handle that?)

The purpose of the API is to allow a mode of operation on all platforms
linux supports.

> This is how to allocate DMA-ready buffers that have certain
> characteristics aren't useful only to the lowest level
> drivers in the stack.  Drivers depend on alloc_coherent to
> behave in the way you (originally) said DMA_MEMORY_MAP works.
> The more detailed API specs (DMA-mapping.txt not DMA-API.txt)
> are very clear that the behavior is like RAM.

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.

> > It can *only* happen if you specify DMA_MEMORY_EXCLUSIVE; that preempts
> > the GFP_ flags and the application must be coded with this in mind. 
> > Otherwise it will respect the GFP_ flags.
> 
> You'd have to change the spec to allow that.  Wouldn't it be
> a lot simpler to just pass the GFP flags down to that lowlevel
> code, so it can eventually start doing what the highlevel code
> told it to do?  :)
> 
> Special cases make for fragile systems.

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. 
Thus this doesn't actually represent a departure.

James