On Fri, Aug 08, 2008 at 12:44:49PM +0100, Catalin Marinas wrote:
> There are already CPUs with weaker memory ordering model than ARM (e.g.
> Alpha) and they are supported by Linux. Of course, there may be problems
> with drivers since most of them are developed in x86.

There are, and they are _constantly_ complaining about drivers not
having the necessary barriers.

Consider that for a moment - how long has Linux supported had weakly
ordered architectures, and how long does it take to fix ordering
problems... 10 or so years?

> > So, in the case of arch/arm/common/gic.c, we should be reading one of
> > the gic control registers after the writes.  In the case of
> > arch/arm/mach-omap2/irq.c, reading the INTC_REVISION reg after masking
> > should be a sufficient solution.
> 
> I need to check in ARM when people come from holidays but a simple LDR
> might not be enough to guarantee that a CPSIE etc. happens after it. You
> may need to add either an LDR + CMP (or some other usage of the loaded
> register) or LDR + DSB. I agree that DSB alone is not enough.

Okay, I give up on this issue.  Weak memory ordering seems to be a
very very big can of worms.  And then there's this:

14:07 < rmk> so we're back to making readl() itself do something with the
             data... which brings us back to that question about why bother
             with weak ordering
14:10 < willy> you can't have weak ordering for device control registers
14:11 < rmk> yes you can, provided they're ordered wrt each other.
14:11 < willy> weak ordering works great for SMP or for just covering up latency
14:12 < willy> no, you can't.  see writel(); readl(); udelay(1); writel();.
               You didn't wait for 1 microsecond before accessing the device
               again.

Or, to put it another way, it seems that on Linux _all_ devices must
be strongly ordered or be seen to Linux as being strongly ordered
(iow, readl and writel and friends _must_ have a barrier.)

And of course, putting barriers into readl and writel, we might as well
use strongly ordered mappings anyway, because that'll save us a few
bytes of program memory.

TBH, this is becoming soo much of a joke, it's untrue.

Let's go back to having a strongly ordered memory model.  Please.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to