>NetBSD/pmax has one obstracle in PMAZ-AA prevents MI ncr53c94 glued
>together.  It handles two different SCSI adaptors DMA-capable IOASIC
>asc and PMAZ-AA TC option card in the same manner.  Cuting-pasting MI
>ncr53c94 code for IOASIC would be little problem, but the code cannot
>cope with PMAZ-AA.  So, simultaneous support for IOASIC/PMAZ-AA with
>MI ncr53c94 needs significant work, probably right support of bus_*
>things and glues in NetBSD/pmax. 

Sadly, even that would not be enough to get the PMAZ-AA working.  The
problem is that some TC devices really can do DMA to host memory, and
(I think) that's what the bus_dma_* functions on the TC bus should support.

For example, I have prototype code which should make Matt Thomas' FDDI
driver work on a pmax.
 
But first-generation TC devices, like the PMAD-A and PMAZ-A, just
cannot do DMA to host memory. They can only do DMA to a relatively
small on-card SRAM buffer (128 Kbytes or so). Software has to copy
between host memory and the SRAM.  We need an additional layer
interposed between the TC bus_space* and bus_dma* functions and the MI
chipset-level code, which copies to and form the on-card SRAM
bounce-buffers.

I'm not sure how to handle this best.  I've talked with Jason Thorpe a
couple of times and we agreed it was problematical.

One idea I had is to insert another level of bus between the TC and
the chipset level, and put the bounce-buffering there. Given how the
autoconfig code and the chipset-level drivers work, that'd probably
mean having a "bus" on the card to handle copying from the SRAM buffer
to the `DMA' address.    

Jason, how does that sound?  Did I forget anything?