Re: RFC: New bus_space routine: bus_space_sync

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Fri, 20 Jan 2012, David Young wrote:

> Date: Fri, 20 Jan 2012 12:48:48 -0600
> From: David Young <dyoung%pobox.com@localhost>
> To: tech-kern Discussion List <tech-kern%NetBSD.org@localhost>
> Subject: Re: RFC: New bus_space routine: bus_space_sync
> 
> On Fri, Jan 20, 2012 at 11:18:38AM +0100, Manuel Bouyer wrote:
> > On Thu, Jan 19, 2012 at 08:45:41PM +0100, Martin Husemann wrote:
> > > Even if originally intended for something else, like Matt says, wouldn't 
> > > it
> > 
> > Why do you think BUS_SPACE_BARRIER_SYNC was intended for something else ?
> > I can't see how a write barrier that doesn't ensure the write has
> > reached the target (main or device memory) can be usefull.
> 
> My understanding of BUS_SPACE_BARRIER_SYNC is that no read issued
> before the barrier may satisfy or follow any read after the barrier,
> and no write before the barrier may follow or be combined with
> any write after the barrier.  Likewise, no read or write before
> the barrier may follow a write or read, respectively, after the
> barrier.  The reads and writes do NOT have to be completed when
> bus_space_barrier(...BUS_SPACE_BARRIER_SYNC...) returns.
> 
> My interpretation of the manual is not very literal, but I believe
> that it's a fair description of what to expect on any non-fanciful
> implementation of bus_space(9) for memory-mapped PCI space, where writes
> can be posted.


No.

Quote:

           BUS_SPACE_BARRIER_SYNC                Force all memory operations
                                                 and any pending exceptions to
                                                 be completed before any
                                                 instructions after the bar-
                                                 rier may be issued.

This means that the write operation must complete before the SYNC returns.  
It means that any caches involved must have been flushed *and* the data 
must have been entered into the registers otherwise you may get an 
asynchronous exception from one of the pending stores.

> bus_space_barrier() is used so little that it may be better to document
> the semantics that are useful and feasible, and make sure that the
> implementations guarantte those semantics, than to spend a lot of time
> on the interpretation.

The semantics seem pretty clear to me.  Now we may have a bunch of buggy 
implementations, but the man page seems pretty clear to me.

Eduardo