All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.