Re: [RFC] generic device DMA implementation

From: David Gibson (david@gibson.dropbear.id.au)
Date: Wed Dec 04 2002 - 19:47:44 EST


On Wed, Dec 04, 2002 at 11:47:14AM -0600, James Bottomley wrote:
> Currently our only DMA API is highly PCI specific (making any non-pci bus with
> a DMA controller create fake PCI devices to help it function).
>
> Now that we have the generic device model, it should be equally possible to
> rephrase the entire API for generic devices instead of pci_devs.
>
> This patch does just that (for x86---although I also have working code for
> parisc, that's where I actually tested the DMA capability).
>
> The API is substantially the same as the PCI DMA one, with one important
> exception with regard to consistent memory:
>
> The PCI api has pci_alloc_consistent which allocates only consistent memory
> and fails the allocation if none is available thus leading to driver writers
> who might need to function with inconsistent memory to detect this and employ
> a fallback strategy.
>
> The new DMA API allows a driver to advertise its level of consistent memory
> compliance to dma_alloc_consistent. There are essentially two levels:
>
> - I only work with consistent memory, fail if I cannot get it, or
> - I can work with inconsistent memory, try consistent first but return
> inconsistent if it's not available.

Do you have an example of where the second option is useful? Off hand
the only places I can think of where you'd use a consistent_alloc()
rather than map_single() and friends is in cases where the hardware's
behaviour means you absolutely positively have to have consistent
memory.

-- 
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson
-
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/



This archive was generated by hypermail 2b29 : Sat Dec 07 2002 - 22:00:21 EST