Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!tektronix!tekcrl!tekfdi!videovax!stever
From: stever@videovax.Tek.COM (Steven E. Rice, P.E.)
Newsgroups: comp.sys.amiga
Subject: Re: 68030, cacheing, DMA devices
Message-ID: <4829@videovax.Tek.COM>
Date: 6 Feb 88 16:23:09 GMT
References: <8179@g.ms.uky.edu>
Reply-To: stever@videovax.Tek.COM (Steven E. Rice, P.E.)
Organization: Tektronix Television Systems, Beaverton, Oregon
Lines: 38

In article <8179@g.ms.uky.edu>, Sean Casey (sean@ms.uky.edu) writes:

> The problem that people have brought up is that a DMA device
> will screw up a system running a data cache.  Since the 68030
> has an onboard data cache, enabling it would screw up things for
> an Amiga, which has several DMA devices.
> 
> It seems to me that the chip designers would have considered this.  *I*
> would have considered it.  Surely the onboard MMU can be told that certain
> pages of memory are not to be cached.  Could someone who has the specs
> for the processor check this out?

The 68030 does indeed have a descriptor for each page that indicates
whether or not the page is cacheable (I/O devices, for instance, should
not be cached!).  In addition, there is a line which allows external
hardware to specify, on a cycle-by-cycle basis, whether data from a
given access should be cached.

This is not the whole picture, though!  If disk I/O is requested,
there is no reason (in principle) that the buffer cannot simply be
malloc-ed and the address passed to the DMA controller.  Unfortunately,
this would then require passing the information to the operating
system that its page descriptor tables need to be updated.

If you have only one DMA device, you can special-case your way around
the problem.  A general solution requires more thought, however, to
avoid losing in system overhead what you gain from DMA.  When you have
a processor with the power of the 68030, the most effective solution
is to hide the I/O devices behind a dual-ported RAM, DMA into the
dual-ported RAM, and then move the data to its intended recipient
with the CPU.

					Steve Rice

-----------------------------------------------------------------------------
* Every knee shall bow, and every tongue confess that Jesus Christ is Lord! *
new: stever@videovax.tv.Tek.com
old: {decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever