ISA Bus Machines = x86 Boxes, Amiga, Alphas, IBM RT, MIPS, Apollo

In no particular order:

The Amiga can be dismissed as a candidate for ISA DMA since;
	a) per tsarna
	- No pc-style DMA controller is included
	- The bridge is one way: zorro cycles can be translated
	- to ISA cycles, but not vice-versa.

	b) If one of the intelligent bridges were to be used, it
	would act as a controller, hiding any details of the ISA
	implementation and also requiring an Amiga specific
	68000/On-board driver, hence would not qualify as
	an ISA DMA implementation.

	c) I very much doubt that any sane manufaturer will ever
	come out with a two way bridge for the Zorro/ISA busses.

The IBM RT, MIPS, Apollo ports will be very well done when
eventually completed, but in the mean time ...

That leaves just the x86 boxes and the Alphas

cgd > ISA DMA is pretty straightforward, in general, on all machines
cgd > (including the alpha), it's just that some of them (the alpha, maybe
cgd > the amiga) REALLY need to have special mapping functions, while others

cgd > the need for machine-specific stuff comes when you're mapping regions
cgd > for dma and unmapping them later (doing bounce-buffer handling while
cgd > you do that).  

mycroft > One thing I would recommend is changing the `iobase' variables to a
mycroft > named, machine-dependent type, such that architectures that do

havard > on-board DMA bus-master.  The AHA-1452 board contains it's own
havard > ISA DMA bus master, and a minimal fix needs to be done there.

Is it possible that the only machine dependent requirement is the
acquisition of the DMA bounce buffers ? In that case why not have
an architecture specific function callable by the driver to do the
actual malloc with a possible parameter as to which bus needs access
to the memory. On some machines/drivers this could even be a simple macro
to return a fixed address buffer.

Patrick Arnoux