I've started looking into implementing this, and the one main thing that
would need to be added is DmaIntr support, which the ncr53c9x MI driver
requires.  The current MD dma routines lack this support.  I'm all in
favor of converting asc, sn, fd, etc. drivers over to use the bus_dma
routines.  This would be a much cleaner implementation in my opinion.
The current dma.c MD implementation is introducing lots of instabilities
with scsi at this point in time... read on...

On Wed, Feb 21, 2001 at 08:10:15PM +0900, Izumi Tsutsui wrote:
> In <87hf1sbrc9.wl@alicia.a-r.org>
> ur@a-r.org wrote:
> 
> > I'm not sure about current arc asc driver status, but I think
> > it should replace to MI ncr53c9x driver.
> 
> I take a look at current asc.c and bus_dma_jazz.c functions,
> and now have some questions:
> 
> 1) I guess jazzio devices use virtual address translated by
>    jazz_dmatlb_*() functions on DMA transfers. Is this right?

From what I can tell, yes.

> 
> 2) Even in MD device drivers, should we use MI bus_dma(9) framework
>    to handle DMA rather than private DMA functions like jazz/dma.c?

I think we should, and in the process eliminate dma.[ch] altogether making
for a must cleaner implementation of DMA.  As far as the jazz-compatible
machines go, we should reduce the asc driver to glue functions which interface
with the MI ncr53c9x driver.  Further, we should rewrite the floppy and
sonic drivers to use the bus_dma functions.  We may also consider making
the sonic driver MI, since other archs (such as mac68k) make use of it.
And the floppy driver needs work anyway, since it doesn't work at present.

> 
> 3) I think DMA buffer which has linear address in CPU VA space
>    can also be mapped to linear jazzio DMA VA space.
>    But current jazz_bus_dmamap_load() calls generic _bus_dmamap_load()
>    and jazz_bus_dmamap_alloc_sgmap(), so returned dm_segs[] would not
>    fit in one segment. Isn't it better to call jazz_dmatlp_map_va()
>    from jazz_bus_dmamap_load() directly like jazz/dma.c:picaDmaMap() ?

Possibly resulting in the data overruns and tlb-miss panics I currently
experience with sustained scsi i/o.  I agree the current setup needs to
be overhauled and streamlined.

> 
> Anyway, I think it is easy to switch MI ncr53c9x driver.
> It's requires only glue functions and some DMA stuff
> like sys/dev/pci/pcscp.c.

Agreed.  I'm willing to help with all of the above, but just keep in mind
that there are those of us using (E)ISA machines without pci.  In any event,
I'm unsure if the current isadma works on the Magnum.  The functions don't
use bus_dma, and assume that there's an 8237A compatible DMA controller
for (E)ISA.  I don't know if this is really accurate, unless the EISA bridge
controller chips provide such an interface.  They may well do.

Cheers,
-Mark