Wolfgang Solfrank wrote:

> Hi,
>
>>>> Yes, modulo the name. Would save us from changing the drivers
>>>> that assume implicit barriers.
>>>
>>>
>>>
>>> I don't like it. The cross product of behviours, bit-widthes and other
>>> options is already enourmous.
>>>
>>> My personal favorite solution is to stick to the documentation,  
>>> explicitly
>>> state so and start fixing drivers (where they are broken).
>>
>>
>>
>> I would rather have a mapping option.
>
>
> Hmm, do we really need a runtime option here?
>
> To me it looks like a driver is either written with explicit barriers
> in mind, or not.  If it is, we can have some appropriate define before
> including <machine/bus.h> and have the bus_space methods leave out the
> implicit barriers.  And document that anyone using that driver (i.e.
> bus specific frontends) have to map the neccessary regions with the
> appropriate flags. 

This won't work (at least not well, I think) in all cases.  The problem 
is that the bus space implementation is not necessarily just macros, but 
be actual functions, and the logic associated with the barriers (and 
whether or not they make sense) may be complex.  Having different 
per-driver behaviors with compile time options in this case may be 
complicated.

You would wind up with something like:

#ifdef USE_IMPLICIT
#define bus_space_write  myarch_bus_space_write_implicit
#else
#define bus_space_write myarch_bus_space_write_explicit
#endif

And then each bus space for that arch would need to define both explicit 
and implicit functions.  For non-cached, ordered spaces, this doubles 
the effort.  Yech.

A run time definition would be simpler to use, understand, and implement.

    -- Garrett

>
> Ciao,
> Wolfgang