Not coherent cache DMA for G3/G4 CPUs: clarification needed

[Gerhard Pircher]

> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh at kernel.crashing.org>
> An: Eugene Surovegin <ebs at ebshome.net>
> Kopie: Gerhard Pircher <gerhard_pircher at gmx.net>,
> linuxppc-dev at ozlabs.org, debian-powerpc at lists.debian.org
> Betreff: Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
> Datum: Fri, 21 Apr 2006 08:41:09 +1000
> 
> On Thu, 2006-04-20 at 14:33 -0700, Eugene Surovegin wrote:
> > On Fri, Apr 21, 2006 at 07:06:13AM +1000, Benjamin Herrenschmidt wrote:
> > > (On 6xx this is deadly even if you don't access those cacheable pages
> > > because the CPU prefetch may do it for you).
> > 
> > Here is another thought if this "prefetch" theory is correct.
> > 
> > You guys seems to focus on 
> > dma_alloc_coherent()/pci_alloc_consistent(), but forgeting about so 
> > called "streaming" mappings.
> > 
> > You cannot just flush/invalidate cache any more, because "CPU can 
> > prefetch this data back". So, to be completely correct (if you insist 
> > on "6xx can prefetch"-theory), you have to actually _copy_ data to 
> > your consistent memory on dma_map_single(). You can imagine 
> > performance implications. I suspect even 440 will be faster in this 
> > case than G4 :).
> 
> Yes.

I'm not sure, if I can follow you here. Would that mean I have to allocate
two consistent buffers of the same size? I guess the first buffer would be
used for the actual DMA transfer and is read only and the second one by the
CPU for further data processing (after the CPU has copied the data from the
first one to the second one)?

Hmm, doesn't sound feasible for me.. ?)

Gerhard

-- 
Analog-/ISDN-Nutzer sparen mit GMX SmartSurfer bis zu 70%!
Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer