This message is from the T13 list server.
Hale's correct; ATAPI does not put any restriction on how much data can be transferred per DRQ block. The device just has to tell us how much is to be transferred in PIO. And for DMA the engine just runs, and at interrupt the ATAPI host will read the "interrupt reason" register to verify that the drive is done transferring, as well as verifying status (and subsequent request sense command upon error) at completion of the DMA transfer. ATA PIO is somewhat different in that the transfer per interrupt is determined at initialization by either single block (512 bytes) when single block PIO is expected by the host, and Nx512 for multi-block PIO when supported by the drive and enabled by the host. Remember the single vs. multiblock selection are driven by the device IdDrive results and the resultant host Set Multiple Mode command (if it so chooses), which becomes a covenant between the host and device on how many sectors will transfer for each interrupt (DRQ block, so to speak) when a Read/Write Multiple is issued. ATA DMA runs just like ATAPI, but without the "interrupt reason" at the end; the status register and error register tell all. MKE. -----Original Message----- From: Hale Landis [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 13, 2001 12:30 PM To: [EMAIL PROTECTED] Subject: Re: [t13] significant byte counts other than the total This message is from the T13 list server. On Thu, 13 Dec 2001 10:05:48 -0700, Pat LaVarre wrote: >In Pio many of our asic's pause at block boundaries in order to TalkLikeWindows. Only ATA devices have a DRQ block size that is a multiple of the device media data block, that being 512 bytes. ATAPI has never had this requirement. The requirement is that the device SHALL NEVER, for any execution of the PACKET command in PIO mode, create a DRQ data block that is larger than the Byte Count Limit size specified by the host when the PACKET command was started. In DMA there has *NEVER* been anything similar to this concept. A DMA data burst can be any size from 2 bytes up to the total size of the data transfer for the entire command. >We have a history of pain involved in enumerating >which Pio devices shipped by other people behave >badly if you don't pause at block boundaries. I am not sure what you mean by "if you don't pause at block boundaries"... Who is "you"? Do you mean the host? The host transfers DRQ data blocks as requested by the device. The host has *NO* choice other than to transfer the number of bytes requested by the device in the Byte Count for the current DRQ block. The device determines when "pauses" happen in PIO data transfers. The host has some control over this via the Byte Cound Limit value. Again, the size of a DRQ data block (or a DMA data burst) is completely and totally unrelated to the device's media data block size. >I'm clear on how a UDma sender can pause at block >boundaries ... I'm not clear on how to use this history >of Pio pain to guide life as a UDma receiver. A UDMA (even MW DMA) receiver of data must be implemented to follow the ATA/ATAPI DMA protocols. Those protocols have no concept of a "block size" and no requirement that burst pause or burst terminations are required at specific times, such as at media data block boundaries. >My best guess is to have the receiver try to cooperate >with a sender who delays for at least a turnaround at >block boundaries, for example after bursting one block >while still reading the next from slow media. Why? Totally unnecessary. If the sender and receiver are properly implemented then this is totally not needed, not required, and sounds like a mess to me. I am sorry but even bridge devices must follow the ATA/ATAPI standards are be implemented as much as possible to look like any other ATA/ATAPI host. *** Hale Landis *** [EMAIL PROTECTED] *** *** Niwot, CO USA *** www.ata-atapi.com *** Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
