Excerpts from netbsd: 7-Jun-97 Re: vme device configuratio.. Jason
Thorpe@nas.nasa.go (2553)

>  >         cgtwo0  at vme0 addr 0x400000 level 4 vect 0xa8 aspace 24
dspace 16
>  > 
>  > 
>  > This would iron out the "kitchen sink" code obio.c and also make
support for
>  > VME on sun4m machines look less contorted.

> The way bus.h would fit into this model would be to have
> multiple bus_space_tag_t's for each of the possible space combinations
> that VME supports:

I'd prefer to get the bus_space_tag_t as return value of a (bus-dependant)
mapping function (similar to the new pci_mapreg_map()) for vaious reasons:
-With individual tags, things become confusing. There are, besides the address
  size, 2 more degrees of freedom: program/data/blt32/blt64 and
  superuser/nonprivileged. This makes in theory 3x4x2 tags (minus some illegal
  combinations) for the different address spaces. If you really want to have
  special tags for different data widths, this makes a factor 3 (there
is a D8 too).
-VME slaves decode address modifiers more or less. Program/data is rarely
  separated, as is the superuser bit. Address space accounting would end in
  a big code duplication. (But I know of at least 1 card which decodes the
  superuser bit, so its existence should not be completely ignored.)
-Allowing the bus dependant code to create handles gives some flexibility
  which could be of use in some cases.

What's the reason to have "data spaces" at all? I don't know of a VME
slave which treats them really differently, besides the fact that D32 is
supported
or not. It's more like a "capability" for me - it could even be negotiated
at mapping time.
There can be a "dynamic bus sizing" too, at least at mc<=68030. I haven't
seen it in newer implementations, but it shows that there there are no
data spaces in the original VME bus concept.

> Quite likely, the bus space read and write methods would be identical for
> all of of the A* spaces,

Shouldn't the normal bus_space_x_n() macros/functions be used here?

> and read/write methods for D* spaces would be
> selectively unimplemented (i.e. cause a panic if used) as appropriate
> (i.e. no bus_space_read_4 in D16 space, for example).

Looking at the i386, this can be unpractical. If a bus_space thing simply
expands to a *(volatile t*), there is no point to intercept.
There can be nasty side effects if illegal operations are done, but I don't
think it's worth much complication - it just makes debugging a bit harder...

> The va_aspace and va_dspace "locators" (more like indicators) are used
> to tell the driver which bus_space_tag it should use.  Alternatively,
> the driver could Just Know, based on which spaces the hardware manual
> for the device says it supports :-)

There should be locators for at least 2 spaces, there are many VME devices
which occupy 2 windows. Even if not directly used - this would help
address space accounting.

I don't know anything about the sun nor hp300 VME bus hardware, so I
might miss some requirements. Hope this helps anyway.

best regards
Matthias Drochner