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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
