谈谈ISA的DMA传输，8237的设置问题

我的ISA板子上有一映射的内存，想通过DMA方式把数据从这个映射内存传输到主板的内存子中，我的DMAC是主板上的8237，不知道我的8237的控制寄存器（命令寄存器）是设置成：存储器到存储器的传输还是设置成I/O到存储器的传输？请大虾指教！！！

我常看的邮箱是zhyzya@163.net，在江苏省连云港市，有空就给我来个email吧。

你回答的真够形象的。好的，硬件上，我是没什么问题了，关于软件的问题，我再开帖子问！真的很感激你的回答！请问你在哪个城市？交个朋友！

你最好加上DMA允许位，我只是说：

如果你家的门没有，但是整幢楼的门确被管理员管得很好，一样也没有危险――你家的门是DMA允许位，整幢楼的门是8237的屏蔽位。

我要撞豆腐啦。

是你说的这个道理，但是，如果外设的DMA请求到来了，我的DMA控制器还没有编程好的话，怎么进行传输，也就是我编程DMA控制器在前，使能DREQ在后，不加使能控制难以做到这点，所以必须加使能！你说呢？

有DMA允许信号是最保险的做法，你能加就加吧。

但我还是不认为它必要：
    操作系统对不使用的DMA通道应该均是屏蔽的，如果驱动又不使用8237的自动重载功能的话，在每次DMA计数完成时，8237均会自行屏蔽该通道。

你回答的很好！确实是这么回事，不知道你做过总线主方式的DMA没有？
这种形式的DMA，驱动编写的时候，要用软件来启动DMA的传输！驱动资料上说，基于包传输（非通用缓冲区）的系统DMA传输和基于包的总线主DMA传输的差别在于：驱动调用IoMapTransfer后，对于系统的DMA，函数调用后系统自动编程好了DMA控制器（例如8237，往里写地址和记数值）驱动只需给设备发送合适的命令来启动DMA的传输，或者说成是驱动发标志位给硬件来告诉硬件可以开始请求DMA了。而总线主的DMA，驱动调用IoMapTransfer后，系统并没有编程DMA控制器（自己板子上自带的），因为系统不知道怎么来编程，得需要驱动编写者自己来做这些事：把IoMapTransfer返回的地址和记数值写到相应的地址和记数寄存器，然后和系统DMA的差不多，发送合适的命令来启动DMA的传输。也就是系统DMA的传输，编程DMA硬件是要系统来做的，而总线主的DMA是要驱动编写者自己来做的。这个我能理解，也是很好理解的。

其实，问你到现在，我的问题还是关于启动传输，是否要软件支持的问题，是必要的，还是不一定需要？

我想，是必要的，理由如下，你分析一下，看有没有道理：假如不用我的软件来使能DMA的传输，那么一旦外设的DREQ来的时候，就表明DMA请求是有效的，我就得响应，来传输数据吧，如果这时候，我还没调用IoMapTransfer编程好我的8237，那么我就不可能响应传输，也就是不可能进行数据的传输了，那么外设也就得不到DACK这个信号了。你说是不是？

不过DMA的优先级没有CPU高，只有CPU有空了才会释放总线给8237，所以才需要FIFO。

从IO到存储器的传输来讲，DMA是CPU访问的2倍，因为CPU要先从IO读到寄存器，再从寄存器读到存储器。

从存储器到存储器的传输来讲，通过ISA总线CPU能1次传输16位，而DMA只能传输8位（8237的特性决定只能进行8位传送）。

用DMA是为了把CPU从简单的数据搬移中解放出来。只有IO和存储器之间的传输可以提高速度。硬件上来看，是因为IO和存储器的访问可以并行，而两次存储器的访问只能串行。

和你聊了这么长的时间了，你回答的很透彻，我还是有个问题：
你说，从我板卡上的映射内存利用DMA方式传输数据到我的主板内存，和用PIO方式从板卡映射内存传输数据到映射内存，哪个传的快点？

我看了一些DMA的资料，现在DMA的内存到内存的传输模式很少用了，因为直接用CPU控制的内存到内存的传输比用DMA的内存到内存的传输还要快，是不是自己板卡上的映射内存到主板内存上的DMA传输也比CPU控制的直接传输要快？？

我很矛盾：上面我说的这些来说要快，但从总线速率（ISA）来看，不可能太快。到底是怎么回事？？

我没有给他留专门的DMA控制寄存器。

是这样的，不过硬件上还是留下更改余地的好，建议使用可编程逻辑器件。

谈了这么多，我想硬件上没有什么不清楚的了。如果你软件上还有问题，重开一帖吧。我还有几句话要说：
（1）DMA取代了CPU的数据搬迁工作，使用DMA的驱动和直接读取FIFO的驱动的区别就在这里。驱动中去掉直接读取FIFO的操作，由启动DMA和有效数据块的操作代替，也就够了。
（2）由于数据填充的时间不可控，所以中断是不可少的。
（3）参考一下IO板卡自带DMA控制器的驱动也有帮助，都需要启动DMA控制器的。
（4）你的设计没有芯片自带DMA功能，所以硬件上有风险。要先在软件干预最小的情况下把DMA功能调出来，再去突破编程难题。故障点超过一个的话，会引发故障隔离的问题。

我的问题也就是软件启动DMA是不是完全有必要，我认为和你说的一样，有的时候必要，有的时候不需要，但是驱动的模式里，确要软件来发命令给硬件以启动传输，是不是有些矛盾？

当时，你写驱动的同事有没有和你讨论这个问题，他当时有没有用软件来启动DMA，也就是你的硬件设计上有没有给他留一些口地址给他来设置DMA，以启动传输？？

我也是这么认为的，我感觉，你帮我做的这个方案，完全是为了满足驱动编写的需要。
现实是，我们硬件的DMA传输可以不需要软件来启动DMA的传输，只是FIFO的半满发请求，8237应答请求，达到数据的传输，在这样的情况下，驱动怎么去写？我想，不能因为软件的需要而把硬件做的复杂，你说是这样吧！

没作过的事，我不敢确定。所以，我也给了一个可写寄存器的方案给你，满足这个驱动编写的要求。

可能因为有的板卡是要软件启动DMA的，情况有很多：
（1）要传输的数据需要判断是否全部有效，如果无效（如奇偶校验错），就不能启动本次DMA，而要清空缓冲区，重填数据。

（2）系统的DMA资源不够，或传输的数据量少，或CPU有充裕的时间进行数据传送，也不需要启动DMA，而采用其他方式。

因此，DMA的允许位对部分板卡是必要的。

我理解，DMA的启动，就是使能DREQ,没有其他的意思.我想你的硬件已经能够完全做好这些事，软件就没有必要来干这个了，软件只是用来设置地址和记数寄存器，和相应的工作寄存器，控制寄存器，是通过调用DDK的函数，来实现的这些功能。所以，我很矛盾，既然硬件能启动DMA的传输，那怎么驱动的模型里面还要我们给设备发送命令来启动传输呢？？

可能是不需要参与，因为8237是有时钟端的，它对DRQ5的判断应该不是利用DRQ5的有效边沿，而是DRQ5的有效电平。所以由驱动启动，还是硬件启动DRQ5，以及启动是在打开屏蔽之前，还是在打开屏蔽之后，都应该没有影响。

你对DMA启动的含义怎么理解的？

你说的很对，硬件能实现的功能，软件就没有必要再添乱了。你以前做的那个DMA的硬件，它的DMA触发条件完全是硬件控制，不需要软件（驱动）来控制，那我想问的是，在这样的情况下，驱动都干了什么？也就是DMA的启动，驱动没有参与！

我以前做过同步串口的DMA，由于同步串口本身缓冲小，接收数据具有瞬时流量大的特点，所以才用的DMA。由于我用的是字符传送模式，且芯片本身有DMA引脚，所以没多少参考价值。

不过我自己在DOS + MASM的情况下验证过DMA。所以我可以肯定的说，DMA也是一种异步突发事件，合适在中断处理程序中处理。硬件和驱动是互相补充的，硬件做了的事软件就不用做了。

你面临的情况是怕万一出现故障，无法定位是硬件还是软件。所以，我认为你不要迷信开发工具，首先用你最熟悉的软件把DMA的功能调出来再说。

你以前做的那个8237的DMA，是不是很简单，没用到这么多的信号来使能DREQ有效？只要满足传输条件就触发DREQ，同时DREQ也就有效了。也就是你的DMA启动是完全由硬件来控制，驱动程序没有来干预启动。
那么你同事的驱动是怎么设计的？他是用的什么工具？？