On Wed, Dec 04, 2002 at 05:21:04PM -0800, Adam J. Richter wrote:
> David Gibson wrote:
> >On Wed, Dec 04, 2002 at 11:47:14AM -0600, James Bottomley wrote:
> [...]
> >> 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?
>
> From a previous discussion, I understand that there are some
> PCI bus parisc machines without consistent memory.
And there are PPCs without consistent memory, except by disabling
cache.
> >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.
>
> That would result in big rarely used branches in device
> drivers or lots of ifdef's and the equivalent. With James's approach,
> porting a driver to support those parisc machines (for example) would
> involve sprinkling in some calls to macros that would compile to
> nothing on the other machines.
>
> Compare the code clutter involved in allowing those
> inconsistent parisc machines to run, say, the ten most popular
> ethernet controllers and the four most popular scsi controllers. I
> think the difference in the resulting source code size would already
> be in the hundreds of lines.
For cases like this, I'm talking about replacing the
consistent_alloc() with a kmalloc(), then using the cache flush
macros. Is there any machine for which this is not sufficient?
-- 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