This message is from the T13 list server.

From: Matt Henson
> After sending the command (Read DMA or Write DMA) the Host DMA
> state diagram seems to require that the host poll the status
> register and DMARQ line until:

You may have missed the discussion a few days ago about all the
places in the host side state diagrams where there is a BSY=1
loop in a host side state diagram.  In this case we are talking
about the "BSY=1 & DMARQ negated" (HDMA0:HDMA0) loop.  This loop
is used only if the host has set nIEN=1.  So the loop should
really be labelled "nIEN=1 & BSY=1 & DMARQ negated".

> [(BSY=0 & DRQ=1 & DMARQ=1) or (BSY=1 & DRQ=0 & DMARQ=1)].  Is it
> really necessary to poll the status register?  Can I just turn it
> over to my UDMA controller, which will wait for DMARQ=1 or
> INTRQ=1?

You should let the host side DMA engine handle the interface
until the host side DMA engine sees the INTRQ signal asserted by
the device; that interrupt should then be passed on to the host
side processor/software.  The host side processor/software should
make no reference to any of the device registers until the
interrupt signalling "command complete" has been received.

Of course there is a "timeout error" case here where the host
side software thinks the DMA engine or the device are hung.  In
this case the host side software should "shutdown" the DMA engine
(so that the DMACK signal is returned to the negated state) and
then the host side software should issue a Soft Reset (SRST).

> It seems logical that the host would not have to read the status
> register until command completion (successful or otherwise) but
> perhaps there is more going on than meets my eye.

The host side should not read the device status until after the
INTRQ assertion from the device has been passed through the DMA
engine to the host processor/software.

Your question(s) about the operation of the host side of DMA
commands are not uncommon.  The host side state diagrams fail to
show that the host really is at least two separate "processes":
1) the host side processor/software that sets up the DMA engine
and starts the DMA command execution, and 2) the DMA engine that
handles the data transfer (all the DMARQ/DMACK handshaking, etc).
I'm not sure how to fix this other than to re-do the host side
DMA state diagrams.  But the confusion here has resulted in
several popular x86/PCI ATA host controllers that will hang the
PCI bus or corrupt the DMA data transfer is the host side does
something legal but unusual.

Hale



*** Hale Landis *** www.ata-atapi.com ***



Reply via email to