This message is from the T13 list server.
Yes the text says to read the x1F5:1F4 AtaCylinder (aka AtapiByteCount) registers ...
... but the diagram per se does not make the need for this step clear?
Yes?
In contrast, previously we had H13: Write_parameters and H14: Write_command. Later on
we have HND1: Check_Status, HPIOI1: Check_Status, etc. ...
Curiously, at first glance, I fail to find a mention of reading the x1F1 Error
register in response to an ERR. Maybe I can hope more hosts will now learn to
tolerate ((x1F1 & xF0) >> 4) != SK of the following op x03 RequestSense?
Pat LaVarre
P.S. I see d1532v3r0.pdf offers "compete" as an alternative spelling for "complete".
>>> "Mcgrath, Jim" <[EMAIL PROTECTED]> 12/13/01 04:47PM >>>
This message is from the T13 list server.
Actually, it is also covered in the state diagram (9.8, Packet command
protocol, host for non data and PIO data transfers):
HP4: Transfer_Data State: This state is entered when BSY is cleared to zero,
DRQ is set to one, and C/D is cleared to zero.
When in this state, the host shall read the byte count then read or write
the device Data register to transfer
data. If the bus has been released, the host shall read the Sector Count
register to determine the Tag for the
queued command to be executed.
This is in accordance with the text I quoted earlier.
Jim
-----Original Message-----
From: Mcgrath, Jim
Sent: Thursday, December 13, 2001 3:22 PM
To: 'Ooi, Thien Ern'; [EMAIL PROTECTED]
Subject: RE: [t13] to Dma from Pio: more Atapi clocks sent?
In ATA-6, revision 3, section 8.23 (Packet command), the byte count limit
register values are set by the host at the time the command is issued - I
think you were referring to these values. "These registers are written by
the host with the maximum byte count that is to be transferred in any
single DRQ assertion for PIO transfers." (8.23.4 Inputs). Note the word
MAXIMUM. It is not the number of bytes transferred per DRQ assertion, jus
the maximum number (in this it is like an ALLOCATION LENGTH rather than a
TRANSFER LENGTH).
In 8.23.5.2 (Data Transmission), "If the transfer is to be in PIO mode, the
byte count of the data to be transferred for this
DRQ assertion shall be presented." "The byte count shall be less than or
equal to the byte count limit value from the host". Specifically this can
be a lower value, and the value can vary every interrupt per command.
This is the value Pat is using in his bridge to tell him how many PIO
transfers to do at this DRQ assertion. It is different from the previous
byte limit, or the total command transfer length (which Pat does not know
since he is not cracking the embedded SCSI/MMC command in the packet)" UDMA
does not have this provision. You do not have periodic DRQ assertions and
various byte limits, which as in essence flow control rules. Instead, you
have to use the UDMA rules (note that the I/O bit and the DMRD bit (set by
the device) tell you direction and whether DMA is supported respectively).
Jim
-----Original Message-----
From: Ooi, Thien Ern [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 13, 2001 10:33 AM
To: [EMAIL PROTECTED]
Subject: RE: [t13] to Dma from Pio: more Atapi clocks sent?
This message is from the T13 list server.
Hi Jim,
Could you elaborate on your statement:
"Today in ATAPI/PIO the receiver in DATA IN gets the byte count explicitly
from the device in the form of register values. The receiver then uses that
to generate the correct number of PIO clocks. "
Isn't is true that the host always knows much PIO data it will transfer when
the command is issued? Does the host need to read the taskfile in order to
determine the amount of data to transfer?
Specifcally, if you look at the protocol for ATAPI/PIO in the ATA/ATAPI spec
(Figure 31: Host PACKET non-data and PIO data command state diagram,
T13/1321D revision 3, d1321r3.pdf), there is no state to indicate that the
host needs to read the taskfile to determine the amount of data to transfer.
So, I conclude that the host must know in advance exactly how many PIO
cycles it is going to issue, when it sees DRQ=1, which doesn't seem to agree
with your statement.
T.E. Ooi
Subscribe/Unsubscribe instructions can be found at www.t13.org.
