Subject: Re: Possibly naiive question about bus_space_barrier & friends
To: Monroe Williams <firstname.lastname@example.org>
From: Jason R Thorpe <email@example.com>
Date: 10/18/2001 13:16:11
On Thu, Oct 18, 2001 at 01:01:29PM -0700, Monroe Williams wrote:
> 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 are correct in that it violates the spirit. The problem is that
changing all the drivers in the tree to use barriers correctly is a...
daunting task. Therefore, the only way to make them work until they
do is implicit barriers.
It might be nice to have _nb ("no barrier") versions of the bus_space
operations so as to explicitly hint that a barrier operation will be
used later... so that we can continue to be lazy and not use barriers
in the current scheme. "Or something."
-- Jason R. Thorpe <firstname.lastname@example.org>