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