This message is from the T13 list server.
Pat, What are you talking about? The device is required to quietly absorb any extra bytes the host send during a UDMA data out (that's in the ATA standard). Why does the host need to be informed that IT SENT OUT MORE BYTES THAN IT INDICATED IT WOULD SEND IN THE COMMAND!! i.e. the host is both the party that sent out the bytes and knew it was not a smart idea. If the host wanted to prevent this in the future it does not need the cooperation of the device. And since no harm was done (i.e. the correct data is written to the device), why would anyone care about correcting it anyway (assuming for the sake of argument that this was difficult for the host to do)? Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Monday, January 28, 2002 12:53 AM To: [EMAIL PROTECTED] Subject: Re: [t13] this UDMA/PIO stuff This message is from the T13 list server. Don C: Glad to hear you still listening, glad to see you posting a third perspective. Speaking now to that third perspective, yes the Atapi details matter: AtapiDma needs an analogue to what you point out Ata 0.5KiB block read/write already has for both Pio and Dma in its x1F2 SectorCount register: a place where the device and the host can look to see whether they have or have not agreed over how many bytes should move. AtapiPio already has such a place: both the device and the host can sum samples of x1F5:1F4 Cylinder (aka ByteCount) taken at DRQ INTRQ time. That sum tells us, of the data bytes clocked, how many bytes the device agreed to move. AtapiDma needs such a place. I'm suggesting a sample of x1F5:1F4 Cylinder (aka ByteCount) taken at x1F2 SectorCount (aka InterruptReason) = x03 StatusIn time i.e. after all data clocks across the bus. That sample "residue" could say, of the data bytes clocked, of Udma bytes included in the UDma Crc, how many bytes the device did not agree to move. For example, to report the device had agreed to move x91 of the x92 bytes included in a UDma Crc, the residue would be 1 = x92 - x91. A less clearly intuitive example is the extreme of UDma Data Out, where a host can inadvertently overestimate the count of bytes a device agrees to move by 2 * X + 1, where X rises with burst rate. I don't mean to be saying we should give the device new freedom to disregard quietly a host's request to move N bytes. I'm trying to say instead we should let the device report if it moved N bytes or something else, so that the host can know to freak out when the device unexpectedly moved something else. I'm asking for Atapi UDma to count bytes moved as precisely as I know Atapi Pio does ... as precisely as now I see Ata 0.5KiB block read/rite does. Pat LaVarre >>> don clay <[EMAIL PROTECTED]> 01/26/02 10:08 AM >>> This message is from the T13 list server. This thread has been followed for some time. If you are designing an X to ATA-x bridge, the following is true on the ATA side. 1. The device has to be told exactly how many sectors to transfer via the Sector Number register whether it be read or write via either PIO or any DMA. 2. The device will transfer exactly that amount of data unless an error is detected by the device, any kind of reset is issued, or a new command is issued. 3. The device will pause data transfer only between sectors by waiting to post the interrupt and raise DRQ in PIO mode or by de-activating DMAREQ in any DMA mode. I am pretty sure that this is exactly true of an ATAPI device as well, but am not 100% sure all of the details. So if you are designing any X to ATA/ATAPI bridge, your bridge has to be incredibly stupid (meaning that you probably have to be incredibly sharp with your design) or, more likely, your bridge will have to translate commands from the X interface to ATA, buffer data, and handle the specifics of managing each interface. Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
