[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: RFC: New bus_space routine: bus_space_sync
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.
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.
Main Index |
Thread Index |