[Top] [All Lists]

Re: a quick question regarding CONFIG_MIPS_UNCACHED..

To: Ralf Baechle <>
Subject: Re: a quick question regarding CONFIG_MIPS_UNCACHED..
From: "Maciej W. Rozycki" <>
Date: Fri, 29 Nov 2002 14:03:00 +0100 (MET)
Cc: atul srivastava <>,
In-reply-to: <>
Organization: Technical University of Gdansk
Original-recipient: rfc822;
On Fri, 29 Nov 2002, Ralf Baechle wrote:

> It's been my observation that hardly any user is aware of these consquences
> nor is the Linux code making a good attempt at complying with all the
> additional restrictions of running uncached.  So in my oppinion
> CONFIG_MIPS_UNCACHED should go.  But I don't feel very strong about it so
> I'm going to wait for a few days so others have a chance to raise their
> voice.

 I completely agree with your points and I'm not fond of this option,
either.  I had a need to run uncached to debug a problem once and even
then it was on the R3k, so I had to set up things differently from what
that option does anyway.  I can't recall the details of the problem, but
coding hooks for an uncached setup took me maybe half an hour, so I don't
think that is a problem for anyone who really needs it.

 BTW, how do you know that ll/sc happens to work for uncached operation on
some processors?  Maybe it simply fails, but the result is subtle enough
not to be observed easily.  A failure may be masked by other factors, e.g. 
for the UP operation, there is normally no way for two parallel requests
for a spinlock to happen and an exception resets the LLbit regardless of
the caching attribute of the area involved.

+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail:, PGP key available        +

<Prev in Thread] Current Thread [Next in Thread>