From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roland Dreier Subject: Re: MMIO and gcc re-ordering issue Date: Tue, 27 May 2008 10:38:56 -0700 Message-ID: References: <1211852026.3286.36.camel@pasglop> <20080526.184047.88207142.davem@davemloft.net> <1211854540.3286.42.camel@pasglop> <20080526.192812.184590464.davem@davemloft.net> <20080526204233.75b71bb8@infradead.org> <1211872130.3286.64.camel@pasglop> <1211906268.3435.44.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from sj-iport-4.cisco.com ([171.68.10.86]:8453 "EHLO sj-iport-4.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757536AbYE0Rsv (ORCPT ); Tue, 27 May 2008 13:48:51 -0400 In-Reply-To: <1211906268.3435.44.camel@localhost.localdomain> (James Bottomley's message of "Tue, 27 May 2008 11:37:48 -0500") Sender: linux-arch-owner@vger.kernel.org List-ID: To: James Bottomley Cc: benh@kernel.crashing.org, Arjan van de Ven , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, tpiepho@freescale.com, linuxppc-dev@ozlabs.org, scottwood@freescale.com, torvalds@linux-foundation.org, David Miller , alan@lxorguk.ukuu.org.uk > Actually, this specifically should not be. The need for mmiowb on altix > is because it explicitly violates some of the PCI rules that would > otherwise impede performance. The compromise is that readX on altix > contains the needed dma flush but there's a variant operator, > readX_relaxed that doesn't (for drivers that know what they're doing). > The altix critical drivers have all been converted to use the relaxed > form for performance, and the unconverted ones should all operate just > fine (albeit potentially more slowly). Is this a recent change? Because as of October 2007, 76d7cc03 ("IB/mthca: Use mmiowb() to avoid firmware commands getting jumbled up") was needed. But this was involving writel() (__raw_writel() actually, looking at the code), not readl(). But writel_relaxed() doesn't exist (and doesn't make sense). - R.