[lkml]   [2004]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] on-chip coherent memory API for DMA
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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:04    [W:0.040 / U:3.320 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site