[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <483FCA94.1060506@sgi.com>
Date: Fri, 30 May 2008 11:36:20 +0200
From: Jes Sorensen <jes@....com>
To: James Bottomley <James.Bottomley@...senPartnership.com>
CC: Roland Dreier <rdreier@...co.com>, 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,
Jeremy Higdon <jeremy@....com>
Subject: Re: MMIO and gcc re-ordering issue
James Bottomley wrote:
>> The only way to guarantee ordering in the above setup, is to either
>> make writel() fully ordered or adding the mmiowb()'s inbetween the two
>> writel's. On Altix you have to go and read from the PCI brige to
>> ensure all writes to it have been flushed, which is also what mmiowb()
>> is doing. If writel() was to guarantee this ordering, it would make
>> every writel() call extremely expensive :-(
>
> So if a read from the bridge achieves the same effect, can't we just put
> one after the writes within the spinlock (an unrelaxed one). That way
> this whole sequence will look like a well understood PCI posting flush
> rather than have to muck around with little understood (at least by most
> driver writers) io barriers?
Hmmm,
I think mmiowb() does some sort of status read from the bridge, I am not
sure if it's enough to just do a regular readl().
I'm adding Jeremy to the list, he should know for sure.
Cheers,
Jes
--
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