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