From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([66.187.233.31]:25241 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S1750792AbWCJPT1 (ORCPT ); Fri, 10 Mar 2006 10:19:27 -0500 From: David Howells In-Reply-To: <17424.48029.481013.502855@cargo.ozlabs.ibm.com> References: <17424.48029.481013.502855@cargo.ozlabs.ibm.com> <16835.1141936162@warthog.cambridge.redhat.com> Subject: Re: [PATCH] Document Linux's memory barriers [try #4] Date: Fri, 10 Mar 2006 15:19:10 +0000 Message-ID: <26486.1142003950@warthog.cambridge.redhat.com> Sender: linux-arch-owner@vger.kernel.org To: Paul Mackerras Cc: David Howells , torvalds@osdl.org, akpm@osdl.org, mingo@redhat.com, alan@redhat.com, linux-arch@vger.kernel.org, linuxppc64-dev@ozlabs.org, linux-kernel@vger.kernel.org List-ID: Paul Mackerras wrote: > > +On some systems, I/O writes are not strongly ordered across all CPUs, and > > so +locking should be used, and mmiowb() should be issued prior to > > unlocking the +critical section. > > I think we should say more strongly that mmiowb() is required where > MMIO accesses are done under a spinlock, and that if your driver is > missing them then that is a bug. I don't think it makes sense to say > that mmiowb is required "on some systems". The point I was trying to make was that on some systems writes are not strongly ordered, so we need mmiowb() on _all_ systems. I'll fix the text to make that point. > There shouldn't be any problem here, because readw/writew _must_ > ensure that the device accesses are serialized. No. That depends on the properties of the memory window readw/writew write through, the properties of the CPU wrt memory accesses, and what explicit barriers at interpolated inside readw/writew themselves. If we're accessing a frame buffer, for instance, we might want it to be able to reorder and combine reads and writes. > Of course, on an SMP system it would be quite possible for the > interrupt to be taken on another CPU, and in that case disabling > interrupts (I assume that by "DISABLE IRQ" you mean > local_irq_disable() or some such) Yes. There are quite a few different ways to disable interrupts. > gets you absolutely nothing; you need to use a spinlock, and then the mmiowb > is required. I believe I've said that, though perhaps not sufficiently clearly. > You may like to include these words describing some of the rules: Thanks, I probably will. David