[This may be of absolutely no interest to you, in which case please ignore
it. I'm just thinking out loud.]

I want to split the PX driver up into a million little pieces. The basic
rationale is that no MI driver exists, and the current code has always been
pretty much 'developmental'. The following cases need to be handled:

- PX vs PXG: For our purposes, the basic differences in terms of interface
  are interrupt handling, DMA, and address-space layout. This is enough to
  justify splitting the board specific code into two distinct modules.

- wscons vs rcons: The wscons interface is pretty standardised except for
  the cnattach gunk. As for rcons, some headway has been made but it's
  pretty much marked for GC at some future point. I don't want to handle
  both with a #ifdef fest.

There are some issues. The most important of these is DMA handling for the
PX. For this to work within the MI framework, some changes need to be made.
This is from a pmax perspective; I don't know about the Alpha side of
things.

- The PX doesn't see anything above 8MB. We need two freelists. One low
  priority list for memory below 8MB, and one higher priority list for
  everything else.

- If the PX is to be useable as a console board, the bus_dma code needs to be 
  work before malloc() is awake. That seems as simple as keeping ?kB of BSS
  for use by pmax bus_dma.c. That's not clean, since it just shifts the
  existing problem elsewhere. Help.

So, my plan as it stands is this:

-- Create a MI VDAC layer that uses the bus_space framework. Why? We currently 
   have a bloody huge rake of code for handling the BrookTree VDACs. Also, a 
   standard API would be delicious. It should:

   - Require two h/w specific routines: xxx_init() and xxx_flush().
   - Cater for immediate update or update at vertical retrace.
   - Fit into the wscons framework with ease.

-- Create a bt459 backend for the VDAC layer.

-- Split the PX driver into 3 pieces: px specific, pxg specific and common.

-- Split the console interface into 2 bits: wscons specific, and rcons
   specific. The back-end shouldn't know which we are dealing with. Since
   the rcons specific bit will be in the pmax tree, it can do all the nasty
   hacks it needs to for X11 (qvss) support via the pmax fb layer.

So, by this logic we'd end up with these source modules:

   - dev/vdac.c:			MI VDAC interface.
   - dev/ic/bt.c:			Cursor 'munge' table for BT VDACs.
   - dev/ic/bt459.c:			bt459 interface.
   - dev/tc/px.c:			Driver for the PMAG-C.
   - dev/tc/pxg.c:			Driver for the PMAG-D, E, F.
   - dev/tc/stic.c:			PixelStamp and STIC interface,
 			                wscons interface glue.
   - arch/pmax/dev/stic_rcons.c:	rcons interface glue.

Comments?