All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: 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:42:46 +0100	[thread overview]
Message-ID: <20021129144246.A13295@linux-mips.org> (raw)
In-Reply-To: <Pine.GSO.3.96.1021129135000.24948B-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Fri, Nov 29, 2002 at 02:03:00PM +0100

On Fri, Nov 29, 2002 at 02:03:00PM +0100, Maciej W. Rozycki wrote:

>  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.

That's a consequence of the simplemost way to implement ll/sc in hardware.
ll puts the physicall address of the the memory reference into c0_lladdr
and sets the ll-bit.  eret clears the ll-bit and finally sc fails if the
ll-bit is cleared.  That's the simplest implementation for a non-coherent
uniprocessor, there is not much more needed that a flip-flop and due to
every designers desire for simplicity a different implementation seem
unlikely.  Btw, c0_lladdr is just a useless gadget here.

It's different for coherent processors, those actually need to snoop on
the bus interface.  On those the simplest implementation is ll generates
a cache line in exclusive state; sc then fails if either the ll-bit has
been cleared; the snooping logic clears the ll-bit if the cache-line's
state changes or an eret is executed.  So the mechanism fails without
caches.

  Ralf

  reply	other threads:[~2002-11-29 13:56 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 [this message]
2002-11-29 14:23             ` Maciej W. Rozycki
2002-11-29 13:49         ` Carsten Langgaard

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=20021129144246.A13295@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=atulsrivastava9@rediffmail.com \
    --cc=linux-mips@linux-mips.org \
    --cc=macro@ds2.pg.gda.pl \
    /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.