Subject: Re: change bus_space_barrier() semantic
To: Garrett D'Amore <garrett_damore@tadpole.com>
From: Wolfgang Solfrank <ws@tools.de>
List: tech-kern
Date: 01/11/2006 12:52:13
Hi,

> 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.

Huh?

Obviously, converting a compile time option into a run time option is easy.
In your case, you could have something like

typedef struct {
	int	implicit_barrier;
	...
} *bus_space_handle_t;

int
bus_space_map_barrier(bus_space_tag_t space, bus_addr_t address,
	bus_space_size_t size, int flags, bus_space_handle_t *handlep,
	int implicit_barrier)
{
	*handlep = ...
	(*handlep)->implicit_barrier = implicit_barrier;
	...
}

#ifdef	USE_IMPLICIT
#define	bus_space_map(s, a, sz, f, h)	\
	bus_space_map_barrier((s), (a), (sz), (f), (h), 1)
#else
#define	bus_space_map(s, a, sz, f, h)	\
	bus_space_map_barrier((s), (a), (sz), (f), (h), 0)
#endif

And testing the implicit_barrier flag in the bus_space_* access functions
(as you would have to do with your approach anyway).

Or are you thinking about something else?

Ciao,
Wolfgang
-- 
ws@TooLs.DE                            Wolfgang Solfrank, TooLs GmbH