On Fri, 2008-08-08 at 14:19 +0100, Russell King - ARM Linux wrote: > On Fri, Aug 08, 2008 at 12:44:49PM +0100, Catalin Marinas wrote: > > 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.) Why not put a barrier in udelay? The delay functions are mainly used for device access. > TBH, this is becoming soo much of a joke, it's untrue. For performance in a multi-stage pipeline model, you need weaker ordering. I'm not a hardware engineer to comment more on this. > Let's go back to having a strongly ordered memory model. Please. On pre-ARMv6, updates to CPSR are guaranteed to take place in program order with a strongly-ordered memory access. This is still true on ARMv6/v7 for backward compatibility but the feature is deprecated and it might not be true for future architecture versions. At some point barriers might be needed. -- Catalin -- 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
