> 
> > > be done. IMHO. It only has to be done once. Yes, I know each driver needs
> > > its own code - which has been made available for at least the AHA1542
> > > series.
> > >
> > The method used in FreeBSD (and IS relatively machine independent) only
> > requires a few 'C' statements in each driver.  The current code calls
> > a '386 specific subroutine (which when the motivation arises -- will
> > be cleaned up and placed in a machine independent portion of the tree.)
> 
> Unfortunately, this IS NOT enough.
> 
> the ISA drivers that do DMA do so by calling vtophys() to find out
> what addresses things are at, and assume that ISA bus pysical
> addresses are the SAME as system physical addresses.
> 
> This just doesn't work on all systems.
> 
The bounce code substitutes a BAD physical address for a GOOD one.  It
handles the case of simple DMAable and non-DMAable ram.  And
for that purpose, it looks sufficient.  Now the general case of handling
multiple busses is a problem.  The best thing appears to be to create
an abstraction that supports the multiple busses.  Couldn't you do
something similar to vm_bounce_alloc, except provide the bus information --
thereby giving a hint as to what bus the I/O needs to be routed to/from???
Right now, on the supported FreeBSD architectures, we have only DMAable,
non-DMAable memory.  So perhaps an additional specification as to the
necessary routing could be provided as an abstraction on FreeBSD and then
the actual implementation would be machine dependent (except for the *simple*
version that would work on problems like the PC/ISA one -- it might be
ifdef'ed.)

(Note also, vm_bounce_alloc is called at a nice place where tsleeps
can be called on resource exhaustion -- like mapping registers, or
bounce memory, etc.)
> 
>  Lots of "painful" info deleted :-).
> 
> I think that the ISA/EISA/PCI bus interfaces -- and maybe even "most
> bus interfaces" -- need to be largely rethought.
> 
Given what you have said -- I can see your point.

John
dyson@freebsd.org