On Mon, Jan 09, 2006 at 10:07:14PM +0000, David Laight wrote:
> On Mon, Jan 09, 2006 at 10:51:40PM +0100, Manuel Bouyer wrote:
> > 
> > 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.
> 
> The problem is that you don't want the overhead of eieio and sync on
> every tranfser.
> 
> You really do need (at least the ability to) leave the synchronisation
> to the driver itself.  Allowing the driver to do series of tranfsers
> before any synchronisation operation.

This is what BUS_SPACE_MAP_CACHEABLE and BUS_SPACE_MAP_PREFETCHABLE are
for.

> 
> Also, separate from the READ_READ and WRITE_WRITE sync requests, you
> need the sync operations for repeated accesses to data fifos.

Sure. bus_space_barrier() as described in the man page can do it, but
it's not implemented :(
There are also device where you need WRITE/READ cycles to get the next
values (always write the address before reading the data).

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