Monroe Williams <monroe@criticalpath.com> writes:

> The thing which surprises me is that bus_space_barrier() is defined as a
> no-op, and the various bus_space_read*() and bus_space_write*() functions
> all call through to functions in pio.h which end with:
> 
> __asm__ volatile("eieio; sync");
> 
> Aside from the fact that sync AFAIK performs a strict superset of the
> operations performed by eieio, this seems like it violates the spirit of
> what bus_space_barrier() is intended for.
>
> Am I missing something basic here, or are the MI drivers in the various
> macppc ports being dreadfully inefficient?

You're right. I encountered the same disappointment when I was working
on the Alpha TGA video driver. We have essentially the same problem on
all platforms with weak memory ordering (alpha and spar64, for
example). The MI drivers do not, in general, use barriers where
necessary; this is at least partly an artifact of the amount of driver
development that is done on the i386, which is more conservative about
memory access reordering.

A transitional solution that has been proposed (it's probably in the
mailing list archives somewhere...) would be to have a preprocessor
symbol that would change the definition of the bus_space functions to
not have implicit barriers. Drivers whose authors were being careful
with barrier ops could define this symbol, and get efficent code; old
drivers would continue to work with the implicit barriers.

        - Nathan