Re: bus_space(9) overrides & resource reservations

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Thu, 27 May 2010, David Young wrote:

> On Thu, May 27, 2010 at 05:20:03PM +0000, Eduardo Horvath wrote:
> > On Thu, 27 May 2010, David Young wrote:
> > 
> > > On Thu, May 27, 2010 at 04:28:19PM +0000, Eduardo Horvath wrote:
> > > > On Thu, 27 May 2010, David Young wrote:
> > > > > You would not use flags, you would install an override function to be
> > > > > used instead of bus_space_read_4().
> > > > 
> > > > Uh, no you wouldn't.  Endianness is set by MMU mappings when the 
> > > > registers 
> > > > are mapped in.  Using the bswap routines on sparc64 is extremely 
> > > > inefficient since they result in 4-8 dependent instructions vs 0 cycles 
> > > > using the mux in the load/store path.
> > > 
> > > You could also override bus_space_map() or whichever routine is most
> > > suitable.  (Did I mention that I've split bus-space reservations and
> > > mappings? :-)
> > > 
> > > Maybe you should have a look at stp4020.c to see if the le32toh() call
> > > in stp4020_read_4() can be avoided.
> > 
> > So... funky_bus.c calls bus_space_tag_create() then bus_space_map() to map 
> > in its regsiters.  At what point do you override the but_space_map() 
> > routine?  I'm still trying to understand how this is supposed to work for 
> > anything other than x86.
> 
> Eduardo,
> 
> Does this problem arise in any MI code that you are aware of?

No.  But no MI code I'm aware of fiddles with bus_space_tags.  Those are 
set up by MD code and passed in to MI routines which only use them.  I'm a 
bit concerned about what could happen once MI code starts messing around 
with what was carefully crafted by MD code without the MD code being aware 
of it.

Eduardo