From: Carsten Langgaard <carstenl@mips.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
atul srivastava <atulsrivastava9@rediffmail.com>,
linux-mips@linux-mips.org
Subject: Re: a quick question regarding CONFIG_MIPS_UNCACHED..
Date: Fri, 29 Nov 2002 14:49:37 +0100 [thread overview]
Message-ID: <3DE77071.17FE9FED@mips.com> (raw)
In-Reply-To: 20021129134230.A11704@linux-mips.org
Ralf Baechle wrote:
> On Fri, Nov 29, 2002 at 12:56:10PM +0100, Maciej W. Rozycki wrote:
>
> > > We've talked about this before - the specification of the ll/sc
> > > instructions says they only work ok on cached memory. In the real world
> > > they seem to work also in uncached memory but I'd not bet the farm on
> > > that, too many implementations out there, too many chances for subtle
> > > bugs.
> >
> > Indeed -- CONFIG_MIPS_UNCACHED should either be removed or imply
> > CONFIG_CPU_HAS_LLSC=n. I suppose there is some interest in the option, so
> > the latter is preferable. That would imply moving the option into the CPU
> > configuration section as now it's set very late, long after
> > CONFIG_CPU_HAS_LLSC is set. Or it could be set up the other way, i.e. the
> > option would only become available if CONFIG_CPU_HAS_LLSC had been set to
> > n. There would be no need to move it then.
> >
> > What do you think?
>
> I had the same thought. So far there are the following groups of people
> using this option:
>
> - Hardware people using it so the the entire program is becoming visible
> externally.
>
> Becoming obsoleted by more advanced, less intrusive hardware debugging
> methods.
>
> - Software people kluding around bugs in their software.
>
> Don't expect me to support this. Note with a line of code.
>
> - For testing if the cache code is actually working.
>
> Will only be useful to show big fat bugs. For the more subtle bugs
> there is no way at all around understanding the entire cache managment
> thing including all subtilities. Actually a good reason to not support
> this option either.
>
> 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 have used this option a lot, it has been very useful in hardware (CPU)
debugging.
>
> Ralf
--
_ _ ____ ___ 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
prev parent reply other threads:[~2002-11-29 13:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-27 9:11 a quick question regarding CONFIG_MIPS_UNCACHED atul srivastava
2002-11-28 15:51 ` Maciej W. Rozycki
2002-11-28 16:15 ` Ralf Baechle
2002-11-29 11:56 ` Maciej W. Rozycki
2002-11-29 12:42 ` Ralf Baechle
2002-11-29 13:03 ` Maciej W. Rozycki
2002-11-29 13:42 ` Ralf Baechle
2002-11-29 14:23 ` Maciej W. Rozycki
2002-11-29 13:49 ` Carsten Langgaard [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3DE77071.17FE9FED@mips.com \
--to=carstenl@mips.com \
--cc=atulsrivastava9@rediffmail.com \
--cc=linux-mips@linux-mips.org \
--cc=macro@ds2.pg.gda.pl \
--cc=ralf@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.