Messages in this thread | | | Date | Thu, 5 Dec 2002 17:15:58 +1100 | From | David Gibson <> | Subject | Re: [RFC] generic device DMA implementation |
| |
On Wed, Dec 04, 2002 at 07:02:18PM -0800, Adam J. Richter wrote: > >On Wed, Dec 04, 2002 at 07:44:17PM -0600, James Bottomley wrote: > >> david@gibson.dropbear.id.au said: > >> > 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. > >> > >> Well, it comes from parisc drivers. Here you'd really rather have > >> consistent memory because it's more efficient, but on certain > >> platforms it's just not possible. > > >Hmm... that doesn't seem sufficient to explain it. > > The question is not what is possible, but what is optimal. > > Yes, it is possible to write drivers for machines without > consistent memory that work with any DMA device, by using > dma_{map,sync}_single as you suggest, even if caching could be > disabled. That is how drivers/scsi/53c700.c and > drivers/net/lasi_82596.c work today. > > The advantages of James's approach is that it will result in > these drivers having simpler source code and even smaller object code > on machines that do not have this problem.
Since, with James's approach you'd need a dma sync function (which might compile to NOP) in pretty much the same places you'd need map/sync calls, I don't see that it does make the source noticeably simpler.
The only difference is that the map functions might also involve iommu or similar setup - which also could compile to a nop in some cases.
> If were to try the approach of using pci_{map,sync}_single > always (i.e., just writing the code not to use alloc_consistent), > that would have a performance cost on machines where using > consistent memory for writing small amounts of data is cheaper than > the cost of the cache flushes that would otherwise be required.
Well, I'm only talking about the cases where we actually care about reducing the use of 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/
| |