Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Gerhard Pircher <hidden>
Date: 2006-04-29 17:57:41
quoted hunk ↗ jump to hunk
--- Ursprüngliche Nachricht ---Von: Benjamin Herrenschmidt [off-list ref] An: "Mark A. Greer" [off-list ref] Kopie: linuxppc-dev@ozlabs.org, 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 +1000quoted
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.quoted
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