From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omx2-ext.sgi.com ([192.48.171.19]:41399 "EHLO omx2.sgi.com") by vger.kernel.org with ESMTP id S268240AbUIPUn3 (ORCPT ); Thu, 16 Sep 2004 16:43:29 -0400 From: Jesse Barnes Subject: Re: RFC: being more anal about iospace accesses.. Date: Thu, 16 Sep 2004 13:42:48 -0700 References: <200409161302.49135.jbarnes@engr.sgi.com> <1095367049.2014.21.camel@mulgrave> In-Reply-To: <1095367049.2014.21.camel@mulgrave> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409161342.48505.jbarnes@engr.sgi.com> To: James Bottomley Cc: Linus Torvalds , Matthew Wilcox , Geert Uytterhoeven , Linux Arch list , Al Viro , Andrew Morton , Alan Cox , "David S. Miller" , Jeff Garzik , Grant Grundler List-ID: On Thursday, September 16, 2004 1:37 pm, James Bottomley wrote: > On Thu, 2004-09-16 at 16:02, Jesse Barnes wrote: > > Note that PCI-X and PCI Express allow a lack of synchronization via the > > relaxed ordering bit. So platforms can either set that bit in their > > iomap functions and deal with synchronization via dma_sync or not use it > > I guess. > > Now you've confused me again. I thought the SGI implementation of this > relaxed read thing was *not* the same as the PCI-X RO bit which was why > you needed a special readX_relaxed? Depends on how you read the specs. I think they're compatible, but others think that PCI-X RO will require a different implementation. We'll know when we see hardware that supports it. > My understanding is that Relaxed Ordering is that it's two bit (i.e. two > separately allowable optimisations) that allow either PIO writes to pass > DMA reads or PIO reads to pass DMA writes (or both) in the stream (I may > have this wrong, I copied Grant because he's been working on this). > > I thought your readX_relaxed was only the first half of this? Only the second half, actually. It may also apply to intra-DMA block ordering. Jesse