Subject: Re: CVS [email-masked]: linux

From: Ralf Baechle <[email-masked]>
Date: Sat, 18 Nov 2000 18:21:15 +0100

On Sat, Nov 18, 2000 at 06:06:39PM +0100, Harald Koerfgen wrote:

> On 18-Nov-00 Ralf Baechle wrote:
> > CVSROOT:      /home/pub/cvs
> > Module name:  linux
> > Changes by:   [email-masked]        00/11/18 05:22:32
> > 
> > Modified files:
> >       Documentation  : Configure.help 
> >       arch/mips      : config.in 
> >       arch/mips/mm   : r4xx0.c 
> > 
> > Log message:
> >       New configuration option CONFIG_MIPS_UNCACHED.  Not yet selectable due
> >       to the manuals documenting ll/sc operation as undefined for uncached
> >       memory.
> 
> Wouldn't it make sense then to disable CONFIG_CPU_HAS_LLSC as well?

I'm waiting for authoritative answer from silicon guys before I deciede.
In the past I ran kernel entirely uncached and they seemed to work even
though the documentation made me assume the opposite.

  Ralf

---

From: Justin Carlson <[email-masked]>
Date: Sat, 18 Nov 2000 10:13:34 -0800

> though the documentation made me assume the opposite.

I'd be very, VERY surprised if ll-sc were guaranteed to work in uncached space,
for any implementation.  It certainly wouldn't in the SB1.

The easiest way to implement the ops on a cache-coherent system is to keep track
of whether or not you've lost a line in the cache between  the ll and the sc. 
Then, in the sc, you convert the line to dirty (if necessary), do the write,
and go on your merry way.  Or, if you've lost the line at some point between the
ll and the sc, you fail the sc.

I've never heard of anyone implementing it in a significantly different manner,
on MIPS or on Alpha.  To keep track of who's written what in an uncached space
would be nightmarish at best, in hardware. 

Doesn't mean someone hasn't done it, but it would certainly be news to me.

-Justin

---

From: "Kevin D. Kissell" <[email-masked]>
Date: Sat, 18 Nov 2000 19:36:41 +0100

> though the documentation made me assume the opposite.

We've been discussing this at MIPS, and it's a bit tricky.
LL/SC is almost guaranteed not to work uncached in a
multiprocessor configuration.  In the uniprocessor case,
it's not documented to work, but probably would in most
"natural" implementations.

The whole operation hinges on an invisible flip-flop which
is set by an LL and cleared by one of a set of events,
which include cache interventions by other CPUs,
memory ops by the same CPU, ERETs, etc.  So long
as the LL flop is set by the LL even uncached, and cleared
on ERET regardless of caching, the desired behaviour will
be obtained in an uncached uniprocessor.  But that's outside
the scope of the ISA spec and any MIPS ISA validation suites,
and a legal MIPS II/III/IV/V implementation could do otherwise.

            Regards,

            Kevin K.

---

From: Dominic Sweetman <[email-masked]>
Date: Sun, 19 Nov 2000 15:16:33 GMT

Ralf Baechle ([email-masked]) writes:

> > >       New configuration option CONFIG_MIPS_UNCACHED.  Not yet
> > >       selectable due to the manuals documenting ll/sc operation
> > >       as undefined for uncached memory.
> > 
> I'm waiting for authoritative answer from silicon guys before I
> deciede.  In the past I ran kernel entirely uncached and they seemed
> to work even though the documentation made me assume the opposite.

ll/sc between CPUs certainly won't work for uncached accesses, since
they rely on the cache coherency protocols.

On a uniprocessor CPU the ll/sc link is typically broken on any
exception.  You'd have to try very hard to design the CPU so that it
would work any differently for cached and uncached accesses.

-- 
Dominic Sweetman
Algorithmics Ltd
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone: +44 1223 706200 / fax: +44 1223 706250 / home: +44 20 7226 0032
http://www.algor.co.uk

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 21 Nov 2000 04:39:03 +0100

> would work any differently for cached and uncached accesses.

Ok, so now CONFIG_MIPS_UNCACHED is only selectable for UP kernels.

  Ralf