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

[Gerhard Pircher]

> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh at kernel.crashing.org>
> An: "Mark A. Greer" <mgreer at mvista.com>
> Kopie: 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, 28 Apr 2006 07:53:29 +1000
> 
> > What Ben says is correct, there is that issue.  However, AFAIK, I have
> > not yet to run into it.
> 
> Hrm... well, I wouldn't rely on that tho.
> 
> > If that hardware workaround is not implemented, the options are:
> > a) 100% chance of a system hang with coherency on
> > or
> > b) < 0.0..1% chance of a system hang with coherency off (at least in my
> > experience to far).
> > 
> > The choice is simple.
> 
> I disagree. A solution that is known to have a hole in it is no good
> even if you haven't managed to trigger it so far. Now it's Gerhard's
> choice.
The choice isn't so simple (at least for me):

I read some old posts of AmigaOS4 developers in the last days. It seems they
just do cache flushes at the beginning/end and during (sync) a DMA transfer.
Also the memory used for DMA is marked as cacheable!? Only the memory used
for the PRD tables (for the IDE controller) is marked as cache inhibited.

I tried to get in contact with some OS4 developers, but I couldn't get an
answer yet. :-(

So I will try out the CONFIG_NOT_COHERENT_CACHE implementation first. As far
as I could understand OS4 does not use BATs for memory mapping, thus the
requisites are not really the same, but it's worth a try. On the other side
I don't understand why the PRD tables have to be in non cacheable memory and
I don't like the idea to modify the Linux IDE driver to do a cache
flush/invalidate for the PRD table memory area.

Thanks again for all your help!

Gerhard

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail