On Mon, Jan 09, 2006 at 03:28:53PM +0100, Wolfgang Solfrank wrote:
> Hi,
> 
> Sorry, I didn't follow this discussion closely enough, but it sounds
> as if you guys are assuming that accessing hardware uncached would make
> barriers superfluous.  E.g.:
> 
> >>Concrete example: wi(4) on mips.  Currently these just "work" because 
> >>the PCI space is mapped uncached.  But the barrier ops for that platform 
> >>issues a cache flush.
> 
> The above is _not_ valid in all cases.  E.g. on PowerPC, the cpu will 
> reorder
> bus cycles even to uncached regions of its bus space.  You have to 
> explicitly
> use barrier instructions to forbid reordering across these borders.

And I think, if I read it properly, this is an example where the
bus_space_read/write implement the implicit barriers I'm talking
about:
static __inline u_int16_t 
__inwrb(a)
        volatile u_int16_t *a;
{
        u_int16_t _v_;

        __asm__ volatile("lhbrx %0, 0, %1" : "=r"(_v_) : "r"(a));
        __asm__ volatile("eieio; sync");
        return _v_;
}

This is the kind of port which wouldn't need to be changed in
my proposal. In fact I don't think any do, or they wouldn't be able to
use MI drivers right now.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--