Messages in this thread | | | Date | Thu, 01 Jul 2004 20:07:44 -0700 | From | David Brownell <> | Subject | Re: [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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |