At 3:36 PM -0400 4/8/02, Hauke Fath wrote:

>Heh... When I looked into my mail this morning and found the 840AV
>question, I did not foresee the thread would become this interesting!

Me neither! Looks like there's more interest than I thought!

>For the bus_dma implementation I started with a copy of the sparc code, but
>quickly dropped that because of the strange hardware they support,

Yikes! The sun hardware is ultra bizzaro. I think the devices have their
own MMU so you have to program their MMU to map in parts of the DRAM. It's
a really cool idea but nobody else that I'm aware of does this sort of
thing. Stay away from the sun port! :-)

> During the last few days, I re-read
>"Designing cards and drivers" wrt. DMA and cache coherency issues.

Cache coherency, or lack thereof, as the case may be. :-) The AV DMA engine
is _not_ cache coherent. You have to flush/invalidate the caches all on
your own. I find it unfortunate that on the 68030 you've also got to do
this for your SCSI card because the 030 doesn't have nearly the same amount
of fine-grained control as the 040. :-(

>I remembered that the macppc's '_dmamap_sync' slot is NULL, started looking
>around in the other ports' code and just yesterday came to the same
>conclusion as you -- pick the next68k implementation.

If x68k is better, I'll take a look at that, but when I was trying to wrap
my mind around what bus_dma() really was all about, it was the NeXT port
that helped me understand what was going on. Thier DMA engine isn't quite
the same but the issues seem very similar.

>>Looking around, I can see that we can pretty much copy the bus_dma()
>>routines from the NeXT port.
>
>Did you? Can we exchange our attempts?

Not yet. I've been busy at work and at home lately. Though I might have
some time in the next few days to poke around a bit.

>At first, the change did me no good. I included m68k/cacheops.c and now get
>an 'illegal instruction' panic early at the return from a routine (_DCFL)
>that for m68030 should be a no-op.

Hmmm. I, too, had problems with caching code. Before I knew about bus_dma()
I tried to modify my driver to flush/invalidate the pages before/after the
transfer but when I called the asm routines to flush/invalidate, the
machine would hang. I think I have to do some 68k manual reading to check
under what circumstances these flushes can be called.

>This sounds as if you knew how to set up the DMA controller... cool!

Yep. The SCSI code was kind of misleading in a few spots, but once I
decoded it, there was a nice section of labeled code in the ROMs that told
me how to start/stop and pause the DMA engine. I must have reviewed my own
version of that code a 100 times to make sure it was correct. So I am
pretty sure I know how to handle the AV's DMA engine now.

Looking at Dave's if_mc code was also a big help, and, if you're
interested, I extracted the ROM's floppy driver, which is written in very
human readable assembly! It pokes directly at the DMA engine, and it helped
me to understand how it works. So I have an example of three different
drivers poking at the DMA. All very enlightening :-)

Speaking of floppy DMA, if somebody could weasel the docs for the floppy
chip out of Nec (I've tried and got the stoney wall of silence!) writing a
driver for the floppy seems like it would be a pretty straight-forward
exercise. That is, given a good DMA engine driver and bus_dma() support :-)

----------------------------------------------
 Michael Zucca - mrz5149@acm.org
----------------------------------------------
 "I'm too old to use Emacs." -- Rod MacDonald
----------------------------------------------