Subject: Re: change bus_space_barrier() semantic
To: Garrett D'Amore <garrett_damore@tadpole.com>
From: Jason Thorpe <thorpej@shagadelic.org>
List: tech-kern
Date: 01/09/2006 15:45:04
On Jan 9, 2006, at 6:44 AM, Garrett D'Amore wrote:

> Seems like an unusual configuration to me.  But it does explain why  
> we have separate degrees of freedom for cacheable and prefetchable.

ARM is even different than this.  In the ARM universe, you have  
cacheable and BUFFERABLE.  Bufferable relates to the write buffer and  
write combining.  Apart from the write buffer, I think ARM has a  
strong memory ordering model.

> It is interesting to me that we assume read/write will be treated  
> the same in our mappings.  Should we allow for seperation of this?   
> Again, I can't think of any concrete examples where caching (as an  
> example) loads vs. stores would be useful.  (I guess you could have  
> buffer that has no side effects for read, but which you can write  
> to -- think a xmit buffer that you wind up going and reexamining  
> for some reason.  Seems a bit contrived though.)

In general, caching of bus space is not useful... when you read a  
register, you bloody well want the effects of reading that register;  
you don't want a potentially cached value.  That said, I can see how  
caching would be useful for e.g. a frame buffer... but in general, I  
think that's limited to things that are "memory-like" (and thus  
prefetchable in the Alpha universe).

-- thorpej