At 9:28 Uhr -0400 9.4.2002, Michael R. Zucca wrote:
>At 3:36 PM -0400 4/8/02, Hauke Fath wrote:
>
>> 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.

There's a technote on the issue ("I was a teenage DMA junkie...") where
Apple makes it clear that the Macintosh is not a DMA machine. It will let
you if you must, but you've got to do the work. Whatever support there is
in the NuBus specs and in the 680[234]0 for multiple busmasters and cache
coherence is disabled. A tradeoff, I suppose -- at the time, noone missed
it.

Which leads to the question: How do we support 2nd level caches (IIci,
IIfx, accelerator boards, 840AV, the AWS95 cache, the Daystar cache cards,
...) when we get bus_dma?

>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. :-(

Well -- the entire 030 cache is not much larger than a 040 cacheline or
two.  ;)

>If x68k is better, I'll take a look at that,

Fortunately, Allen has picked up the ball, so we may see an MI
implementation soon. As I said, the differences between the m68k ports'
bus_dma ways are not that great, it's just that x68k has re-structured a
few things.

>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.

Well, "in principle" DMA is a simple thing...

>>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.

I integrated the x68k _dmamap_sync() and its helper functions, and after I
removed a previous low-level attempt at flushing the cache (pulled from
amiga, iirc) -- voilą! -- I finally got identical output from 53c720
accesses to main memory as to its board RAM. Meaning, the thing actually
does DMA via NuBus, and gets its scripts allright. Success!

The driver still doesn't find anything on the bus, but you cannot expect
all at once.  ;)

>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 :-)

At least the bus_dma seems 'just round the corner'.

	hauke


--
/~\  The ASCII Ribbon Campaign        "They that can give up essential liberty
\ /    No HTML/RTF in email           to obtain a little temporary safety
 X     No Word docs in email          deserve neither liberty nor safety."
/ \  Respect for open standards                     -- Benjamin Franklin, 1759