This message is from the T13 list server.
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 -----Original Message----- From: Mcgrath, Jim [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 11, 2001 5:57 PM To: 'Pat LaVarre'; [EMAIL PROTECTED] Subject: RE: [t13] to Dma from Pio: more Atapi clocks sent? This message is from the T13 list server. [..] So except for the possible odd byte residue problem, I still cannot see why there is a problem. 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. In ATAPI/UDMA the receiver gets the byte count from latching the clock transitions from the sender. The sender is sending the clocks, so the receiver does not have to worry about that. In either case the receiver always knows the number of bytes sent, and the information is ultimately always derived from actions of the device. The bridge can rely on that value just as well for either protocol - it just gets it in different ways. Jim Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
