Subject: Re: change bus_space_barrier() semantic
To: Manuel Bouyer <bouyer@antioche.eu.org>
From: David Laight <david@l8s.co.uk>
List: tech-kern
Date: 01/09/2006 22:07:14
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.

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

	David

-- 
David Laight: david@l8s.co.uk