Messages in this thread | | | Date | Thu, 5 Dec 2002 13:40:39 +1100 | From | David Gibson <> | Subject | Re: [RFC] generic device DMA implementation |
| |
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/
| |