newbus IO ordering semantics - moving forward

[Marius Strobl]

On Fri, Oct 28, 2011 at 05:05:50AM +0800, Adrian Chadd wrote:
> On 28 October 2011 04:39, Matthew Jacob <mj at feral.com> wrote:
> 
> > No. Please don't change the current semantics which are well understood if
> > only fitfully adhered to. This would put us in the position of having some
> > drivers possibly work slower because they didn't do the "lazy" request.
> >
> > I also am not sure I agree with your characterization of linux semantics.
> 
> Hi,
> 
> The point is, all (most?) of the bus glue does flushes if needed. Ie,
> if I understand what's going on:
> 
> * amd64/intel, it's not needed;
> * mips doesn't implement it yet;
> * ppc (and sparc?) implement a bus flush on each operation anyway.
> 

For sparc64 this statement is false; the bus_space(9) implementation
there relies on drivers properly using bus_space_barrier(9), mainly
because bus barriers are a rather costly operation there and including
them with every bus access for the most part probably unnecessarily
just wastes performance. Also virtually all drivers enabled in the
sparc64 GENERIC properly issue bus barriers AFAICT as we took care of
this when porting "MI" drivers over to work on sparc64 (fixing
endianess issues, incorrect use of bus_dma(9) etc). Also ath(4) once
worked fine on sparc64, at least when it was added to GENERIC, if
it no longer does (which it likely doesn't when bus_space_barrier(9)
calls are missing) then this is a regression in ath(4).
Also if you count in bus_dma(9) on "bus glue" then the statement that
it automagically does flushes if needed also is false; bus_dmamap_sync(9)
calls are vital even on x86 in order for bounce buffers to work.

Marius