On Thu, 1 Aug 2002, Ralf Baechle wrote:
> R10000.
OK. Any specs anywhere?
> Back in time I prefered CONFIG_NONCOHERENT_IO over CONFIG_COHERENT_IO
> because the noncoherent case needs additional code and in general I'm
> trying to reduce the number of the #if !defined conditionals for easier
> readability.
Hmm, what's wrong with "#ifndef"? Not much less readable than "#ifdef",
IMO.
> The R10000 is our standard example why looking at the processor type doesn't
> work. It's used in coherent mode in IP27 but in coherent mode but in
> coherent mode in IP28 or IP32. Otoh I don't know of any system that
> supports coherency but also is being used with non-coherent processors.
Yep, I suppose so, but the first criterion should be the CPU anyway.
Basically:
1. Does the CPU support coherency?
2. If so, does the system?
I'm going to express it this way in the config script.
> > Using a non-coherent
> > configuration for an UP system that supports coherency (do SGI IP27 and
> > SiByte SB1250 have another agent in the chipset that may issue coherent
> > requests regardless of the number of processors started?)
>
> Yes. That's how coherency is working - all agents have to support coherent
> requests or coherency simply won't work. So basically we'd be trully
> picky we'd have to verify that all agents, processor and other support
> coherency but just using the system type seems to be sufficient.
Well, inferring from docs and my experience it's not needed. A system
may simply require areas used for DMA to be marked as non-coherent by
CPUs. Often uncached accesses are used to prevent spoiling the caches
anyway.
> > results in a
> > performance hit only due to superfluous invalidations, but using a
> > coherent configuration for a processor/system that doesn't support it may
> > lead to a hard to debug hang with no apparent reason (as I wrote
> > previously, even NMI/Reset stopped working on my system -- I had to hit
> > the power switch).
>
> Using a non-coherent mode on IP27 may result in nice, hard to trackdown bus
> errors.
Weird, but I accept it as a fact. Still a bus error expresses more than
a hang. ;-)
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
|