[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <adad4n71wb3.fsf@cisco.com>
Date: Tue, 27 May 2008 10:38:56 -0700
From: Roland Dreier <rdreier@...co.com>
To: James Bottomley <James.Bottomley@...senPartnership.com>
Cc: benh@...nel.crashing.org, Arjan van de Ven <arjan@...radead.org>,
linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
tpiepho@...escale.com, linuxppc-dev@...abs.org,
scottwood@...escale.com, torvalds@...ux-foundation.org,
David Miller <davem@...emloft.net>, alan@...rguk.ukuu.org.uk
Subject: Re: MMIO and gcc re-ordering issue
> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists