Subject: sparc bus changes
To: None <port-sparc@NetBSD.ORG>
From: Paul Kranenburg <pk@cs.few.eur.nl>
List: port-sparc
Date: 02/01/1998 00:12:28
I'm making the sparc sbus/obio drivers fit the bus_space(9)/bus_dma(9) model.
Hopefully, this will result in those drivers being far less dependent
on cpu archicture quirks, so for instance, someone doing an ultrasparc
port needn't worry about adapting sbus drivers (too much..).
It also might result in code shareable with the sun3/sun3x.

The approach I'm taking is this:

	- all drivers that attach to multiple busses now will get
	  split attachment routines, e.g.:

		attach <device> at sbus with <device>_sbus
		attach <device> at obio with <device>_obio

	- each bus (sbus, sun4/obio, sun4m/obio, sun4c/mainbus) will
	  have its own attach arguments in stead of the Grand Union
	  `confargs' we have now (it used to be more or less like this
	   before the sun4 code got merged in many moons ago)

	- each bus will export bus map functions (e.g sbus_bus_map())
	  and DMA handling routines, per `bus_{space,dma}(9)'
	  Note that in sbus drivers I'm currently not using the bus
	  map macros defines in bus_space(9) directly, since device
	  I/O space addresses do not smoothly fit an integral `bus_addr_t'.


I'm currently planning to handle the sun4 vs. sun4m obio bus by just
lumping the attach args together in a discriminiated union, where
the sun4m obio case is in fact an sbus attach structure.

Another quirk I've yet to work around is the use of `bus_dmamem_mmap()'
in frame buffer drivers, which just seems plain awkward given the
way "real" DMA is done on sparc and sun3s.

-pk