Re: [update] [patch] linux: Cache coherency fixes

[Carsten Langgaard <carstenl@mips.com>]

"Maciej W. Rozycki" wrote:

> On Thu, 1 Aug 2002, Ralf Baechle wrote:
>
> > Looks mostly right except that the code in config-shared.in which deciedes
> > if a system is coherent is wrong.  Basically it assumes every R10000 or
> > every uniprocessor system is non-coherent and that's wrong.  As coherency
> > between CPUs and for DMA I/O is basically the same thing I've changed your
> > code from the use of CONFIG_CPU_CACHE_COHERENCY to CONFIG_NONCOHERENT_IO
> > which did already exist; I don't think we need another config symbol to
> > handle this.  Will apply once I did a few test builds and patches the
> > whole thing into 2.5 ...
>
>  Huh?  Coherent caching mode can be used for a few processors only, namely
> R4[04]00MC and presumably SB1 (inferred from the sources), i.e. the ones
> that support the interprocessor coherency protocol.  If you know of any
> other processor that supports the protocol, I'd be pleased to see a
> reference to a spec -- I hoped someone, possibly you, would fill the
> missing bits when I proposed the patch a month ago.  Nobody bothered,
> though, sigh...

The 20Kc has support for cache coherency, but it doesn't support Coherent
Update on Write (CUW), it only support Coherent exclusive (CE).

The way I implemented the coherency support locally, was I used a boot option
(coherency), where I could tell whether I wanted to run coherent or not.
The dma cache routines would then either be the normal (non-coherent version)
or a empty function.
As my system (a Malta board) can have different daughter cards attached, I can
have different CPUs and system controllers and I really like the idea, that I
can run the same kernel on all the different system setups.
So if the kernel was started with the "coherency" option, I checked whether or
not the CPU and system controller has support for coherency or not, if one or
both didn't support coherency, I die telling the user that the system didn't
support coherency.
In both the coherency and non-coherency case, I used the write-back
non-coherent cache attribute, as the 20Kc still responses to Intervention and
Invalidate request from the system controller.
The coherent exclusive cache attribute is really only needed in multi CPU
systems. I don't know if other CPU works the same way as the 20Kc.



>
>  I see your changes are broken conceptually, as the caching mode for the
> TLB should be inferred from the CPU configuration in the first place and
> not the system selection (actually it should be best selected ath the run
> time).  Hence I'd invert the flag, since most systems are non-coherent,
> and only permit it for certain processors.  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?) 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).
>
>  I'll cook another patch to fix what got broken.
>
>   Maciej
>
> --
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com