On 16 Nov 2000 eeh@netbsd.org wrote:

> Huh?  I'll admit that bus_space_barrier lacks some of the 
> flexibility of the barriers available on some architectures,
> but a BUS_SPACE_BARRIER_WRITE barrier should be sufficient
> to ensure the write completes.
[...]
> 	Another, more plausible example, is a network card (something like an
> 	i82586) attached to an ISA bus.  It has some memory (accessed through the
> 	ISA memory space) and some registers (accessed through the ISA I/O
> 	space).  To transmit a packet, we compose the packet in the board's
> 	memory, then poke one of its registers.  We clearly need some kind of
> 	write barrier between writing to the memory and the registers, but they've
> 	got different bus_space_tags, and bus_space_barrier doesn't provide for
> 	barriers that span more than one tag.
> 
> The reason for that is that it is possible for different buses
> to have different caching.  In this case you would issue the
> a BUS_SPACE_BARRIER_WRITE on the board's memory to make sure
> that completes, then poke the register and issue another
> BUS_SPACE_BARRIER_WRITE on that register to complete that
> bus cycle.

In both of these cases, you seem to disagree with bus_space(9), which (at
least in revision 1.12.4.2, which I've got convenient access to) states:

     All of the specified type(s) of operation which are done to the region
     before the barrier operation are guaranteed to complete before any of the
     specified type(s) of operation done after the barrier.

i.e. the barrier only guarantees the _relative_ timings of writes before
and after the barrier call, and then only for writes in the region
specified by the barrier.  Thus, issuing a barrier doesn't guarantee that
pending writes have been pushed to the hardware (which is likely to be
very slow), but merely that they'll reach the hardware before any writes
issued after the barrier.  If this isn't how barriers are meant to work,
bus_space(9) needs to be corrected.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>