Subject: Re: Problems configuring SCSI disks
To: Toru Nishimura <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 02/11/1998 19:24:36
>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
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?