** This is the quasi-official and semi-temporary T13 email list server. **
A minor correction of one part of Hale's response:
"And if this happens while a DMA burst is
"active" the host controller must terminate the current DMA
burst, by deasserting DMACK, and allow the IOR-/IOW- cycle
through to the device. Of course the device will probably keep
DMARQ asserted during this time and after the host's IOR-/IOW-
cycle has completed, the host controller will assert DMACK and
pick up the DMA transfer as if nothing had happened."
This is correct for Multiword DMA, but not for Ultra DMA. The host can
never just deassert DMACK- and do an IO cycle with the drive having DMARQ
still asserted. Instead, it has to legally terminate the DMA burst by the
following sequence:
* host pauses data flow (with pause or just stops clocking, depending
on the direction of data flow)
* host asserts STOP
* host waits for device to deassert DMARQ
* host sends CRC bytes
* host can then deassert DMACK-
Without following this interlocked sequence (which always leaves DMACK- and
DMARQ deasserted) you cannot do the CRC comparison and so have to declare
the burst as being invalid (not only that, but the device still thinks DIOW
and DIOR are defined as they are in DMA bursts!). This in turn will result
in eventually failing the command (not a good thing to do if you were trying
to poll for STATUS to begin with!).
Of course, Hale is correct that all of this is invisible to the host
software. And for those of you who may think this is too much time, it is
typically around 300 ns to complete the burst termination sequence (if the
host acts fast) - far faster than the 1 us required for the actual IO access
in PIO mode 0.
Jim
PS technically table 10 should be updated - it says that the register access
rules do not apply to Ultra DMA when DMACK- is asserted (i.e. during a DMA
burst). There is a lot of sections that say you cannot do a PIO while
DMACK- is asserted (for instance, all of the register descriptions), but
since table 10 is covering every case but this one it seems a shame not to
cover this as well (maybe this is done in ATA 6?).
-----Original Message-----
From: Hale Landis [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 11, 2001 11:00 PM
To: [EMAIL PROTECTED]
Subject: [temp t13] Re: Are devices allowed to go busy on their own?
** This is the quasi-official and semi-temporary T13 email list server. **
Jim McGrath quoted ATA/ATAPI-x:
>Multiword DMA (cannot access registers in Ultra DMA mode, as per
>table 10): "during the data transfer of DMA commands either the
>BSY bit , the DRQ bit, or both shall be set to one;"
This is correct but we must be very careful here so we don't
confuse anyone...
It is legal for a host to read any of the Command block registers
or to read the Alt Status or write the Dev Ctrl register while a
DMA command is executing and even while a DMA burst, MW or Ultra,
is "active" within that command execution. But it is "DMA burst
active" that must be understood in full detail...
A DMA burst, MW or Ultra, is "active" when both DMARQ and DMACK
are asserted. On most systems (x86 especially) the host software
has no idea when a DMA burst is "active". However host software
is allowed to issue IOR-/IOW- cycles to the device during DMA
command execution. And if this happens while a DMA burst is
"active" the host controller must terminate the current DMA
burst, by deasserting DMACK, and allow the IOR-/IOW- cycle
through to the device. Of course the device will probably keep
DMARQ asserted during this time and after the host's IOR-/IOW-
cycle has completed, the host controller will assert DMACK and
pick up the DMA transfer as if nothing had happened. Host
controllers must work this way in order for polling hosts (hosts
that don't use interrupts) to operate correctly when using the
DMA commands in MW or Ultra DMA (yea, it is not the ideal way for
a host to operate, but it is legal).
If during a DMA command the host issues a IOR- to read the device
status (just what a polling host would do) the host may see BSY=1
or BSY=0 DRQ=1. Either are OK and either indicate a command is
in progress.
So be careful... It is legal for a host to access the device's
registers during a DMA command including during a DMA command
that uses Ultra DMA. It is just that such activity can cause a
DMA command to require *many* DMA bursts to transfer all the
data, perhaps several hundred small DMA bursts per sector
transferred. Actually this is a great host and device data
integrity and flow control test.
Now if someone wanted to build a smart host controller they would
make their controller respond to the host read of any Command
block register or the Alt Status register with the value 80H (or
maybe DOH?) so that the DMA burst on the ATA interface need not
be stopped and restarted. I am sure that would make host
controller design less complex -and- it would not remove the
performance problem a polling host can have today.
(Oh yea, I am sorry! I forgot that this interface is about to be
replaced by a proprietary "serial" interface... What was I
thinking when I wrote the previous paragraph? Why would anyone
want to waste their time and money designing a much better host
controller when the current interface is about to become
obsolete?)
*** Hale Landis *** [EMAIL PROTECTED] ***
*** Niwot, CO USA *** www.ata-atapi.com ***
--
If you have any questions or wish to unsubscribe send a
message to Hale Landis, [EMAIL PROTECTED] To post to
this list server send your message to [EMAIL PROTECTED]
For questions concerning Thistle Grove Industries or TGI's
list services please send email to [EMAIL PROTECTED]
--
If you have any questions or wish to unsubscribe send a
message to Hale Landis, [EMAIL PROTECTED] To post to
this list server send your message to [EMAIL PROTECTED]
For questions concerning Thistle Grove Industries or TGI's
list services please send email to [EMAIL PROTECTED]
