> --- Ursprüngliche Nachricht --- > Von: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > An: "Mark A. Greer" <[EMAIL PROTECTED]> > Kopie: [EMAIL PROTECTED], debian-powerpc@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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
