On Tue, Dec 04, 2007 at 07:52:50AM +1100, Benjamin Herrenschmidt wrote: > > #address-cells = <1>; > > + #size-cells = <1>; > > + model = "Katana-Qp"; /* Default */ > > + compatible = "emerson,Katana-Qp"; > > + coherency-off; > > + > > What do that mean (coherency-off) ? > > Somebody is trying again to use a 74xx with non cache coherent DMA ?
Hi Ben. I suspect Andrei got that from the prpmc2800 dts which I made so I'll jump in. (BTW, this is the same debate we have every year or two. :) By looking at the dts, that board has an mv64460 which has a couple issues when it comes to coherency (depending on the rev of the chip). One is about not being able to use DCBST instructions with coherency on and the other is about limiting the length of one of the traces (which at least one board manufacturer that I know of refuses to implement). The first one is supposed to be fixed by rev A1 of the part and the second is supposed to be fixed by rev B0 of the part. I don't know what rev(s) are on the board(s) Andrei is using. If its B0 or later, in theory, the part should work with coherency on. Andrei, have you tested with coherency on? -- As far as the prpmc2800 (mv64360)... [I don't know what an NDA let's me say or not so I'll just give summaries of the errata. If you or another reader has signed the NDA you/they can look them up.] I don't recall all of the details anymore but these are the errata I saw by quickly scanning the 64360's list. - "FEr CPU-#1": Basically the CPU could read a stale cache line. Supposed to be fixed in rev A2 & B0 but I haven't verified. - "FEr MPSC-#1": The MPSC can't access a coherent memory region. This is pretty much a show stopper for the prpmc2800. There are no plans to fix that erratum. - "FEr PCI-#4" (Detailed by Application Note AN-84): [This isn't strictly a coherency issue but having coherency enabled exacerbates the problem.] Basically, the bridge can let the cpu read a pci device's registers before all of the data the PCI devices has written has actually made it to memory. This and the fact that the device's write data may be stuck in the PCI Slave Write Buffer (which isn't checked for coherency), the cpu can get stale data. There are no plans to fix that erratum. - "FEr PCI-#5" (Detailed by Application Note AN-85): With certain PCI devices and with coherency enabled, some combinations of PCI transactions can cause a deadlock. There is a workaround documented but I've tried it and it didn't work for me (but I can't be sure that was the erratum I was bumping into). There are no plans to fix that erratum. -- So, the answer depends on what part & what rev of the part you have (e.g., the pegasos doesn't use the MPSC and apparently has the other issues worked around so it can turn on coherency but the prpmc2800 doesn't so it needs coherency off). BTW, I haven't forgotten the inherent bug you described when coherency is off (/me too lazy to find link to the email) but AFAIK I've never run into it. However, if I turn on coherency and stress the PCI bus, it hangs (I can't even look at memory thru a bdi). Mark _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
