Checkpoint of development of the following features of mvme68k:

 . Preliminary support for the MI VMEbus framework.
 . Full bus_space* and "mostly-there" bus_dma* support.

At this time, MI VMEbus drivers may well work 'as is' on an MVME147 board.
Work to get the MVME167 to this stage is ongoing.

Testers will be required at some point as I have no VMEbus boards which
have existing MI drivers! (Although I am able to test things in a limited
fashion using a noddy driver and a VMEbus RAM card).

TODO:

 . Expunge all remaining use of IIOV() and freinds.
 . Flag the 'boot device' using bus_space_tag_t and offset.
 . Add a 24bit address constraint to bus_dmamem_alloc() (for le/ie)
 . VMEChip2 support on MVME167/MVME177
 . Support the mvme68k boards in VMEbus slave mode.
 . Anything else I can thing of, besides having another beer. ;-)
Add constraints for bus_dmamem_map() to allow allocation from onboard
RAM only, and/or restricting physical addresses to 24-bits.

Also make bus_dmamem_map() actually honour the BUS_DMA_COHERENT flag.
One step closer to getting the VMEbus glue working on mvme167 ...
s/segs/nsegs/
s/v/va/
VMEbus support on mvme167 is now pretty much coded for.
Now all I need to do is test it... ;-)
Get rid of PCC{,TWO}_VADDR(), and some general tidying up.
MI VMEbus glue more or less complete.
Kernels now compiled with -Wall, etc. (lots of fixes needed for this)
All MD drivers now bus_spaced/bus_dma'd. The two SCSI drivers should
be replaced with bus_spaced MI versions at some point.
Fix local-bus offset of VMEbus windows.
Houston, we have VMEbus interrupts.
Also address some KNF issues.