Subject: Re: DMA beyond end of isa
To: None <Chris_G_Demetriou@niagara.nectar.cs.cmu.edu>
From: Bill Studenmund <wrstuden@loki.Stanford.EDU>
Date: 01/04/1996 22:34:05
> > Is it possible that the only machine dependent requirement is the
> > acquisition of the DMA bounce buffers ?
> as i've said before, NO.
> There are a lot of other machine-dependent, and even "hardware that's
> in your machine"-dependent requirements.
> for instance, should 'inw' and 'outw' byte-swap their arguments,
> and/or how should they be swizzled to poke into memory at the right
> place? as i understand it, the need to byte swap on amiga ISA
> bridges is dependent on which particular bridge you're using.
> Everything about how to do inw, outw, inb, outb, etc., is
> machine-dependent on the alpha, from: what _BUS_ to do it on
> (there can be mutiple ISA/EISA/PCI busses on some alpha systems!),
> to what bit positions in the word written to memory the data has to go
I've been kinda following this thread, and wanted to contribute one
more port which will be using ISA DMA: the CHRP (Common Hardware
Reference Platform) one. True, it hasn't been announced yet, and
spec-compliant machines are 6 to 12 months away, but it's the direction
Apple's going, Motorola's going, part of IBM's going, and the
reason I've put off getting a new Mac; mine will be CHRP-compliant.
The outline of the spec is one or more PowerPC's on a PCI bus connected
to a PCI-ISA bridge. A chip on the PCI side impliments most of the
Mac's hardware, and chips on the ISA side do most of a PC's (such as
soundblaster-compatable audio, COM1-COM4, LPT1, PC keyboard, etc.)
I/O. Most of the IO will be accessable little-endianly and
big-endianly (the video buffer in particular).
Since the machines are a ways off, I'm just wanting to say that eventually
making platform-independent code will be a big win.
[more details of points-of-pain deleted]
> I don't think it's a good thing to say "these ports are not yet done"
> (some of them _are_ nearly "done," and by the "is it all in the source
> tree metric, the Alpha port isn't even done!) when determining how to
> properly implement an ISA bus abstraction to be used by
> machine-independent drivers. Otherwise, you'll end up rewriting much
> of the ISA code N times, where N is probably log2 of the number of
> ports that use it.
True, but I would like to suggest that, in the beginning, a bit of this
duplicity might be good. As many might have guessed, I'm involved with
the mac68k port. We (I) just ported the serial driver from the sun/sparc
ports, after much hacking. Now, for a second pass, I'm going to go
back and do it again. Also, there's an effort to make a machine-indep.
z8530 chip driver, and a lot of what I've learned will (hopefully :-)
enhance the M.I. effort. So try something, and see what works. Maybe
iterative-refinement w/ occasional massive rewrites would be best?