This message is from the T13 list server.
On Tue, 16 Apr 2002 11:28:32 -0600, Pat LaVarre wrote:
>This message is from the T13 list server.
>Please reply again to confirm/ deny/ correct my understanding.
OK, but I would like you (Pat) to confirm your understanding of
some of the items below... they are clearly marked...
>When the host & the device do agree over how many bytes to copy
>which way, life is delightfully simple.
In the ATA/ATAPI world, the ONLY way ATA/ATAPI works is when this
is true.
The following discussion applies ONLY to the ATA/ATAPI interface
and the communication between the ATA/ATAPI host and the
ATA/ATAPI device. The discussion has nothing to do with how OS
driver stacks or application programs operate.
Definition: BROKEN = Does not conform the the requirements of
the published ATA/ATAPI standards.
For all ATA/ATAPI commands, including an ATAPI PACKET SCSI CDB,
these are mandatory requirements for every command:
a) The command exactly defines the direction of data movement.
Pat: Please confirm that you understand that this (a) is a
basic requirement for ATA/ATAPI to operate correctly.
b) For write commands the command defines the exact number of
bytes that SHALL be transferred to the device, plus perhaps a pad
byte. The host SHALL have this number of bytes ready to
transfer, plus perhaps a pad byte. The host is NOT allowed any
other option, NO option to have less bytes, NO option to have
more bytes. The device shall transfer this number of bytes OR
end the command with an error. In PIO and DMA there are no extra
or residue bytes. None, never. The device shall not request
less data unless it intends to terminate the command with an
error. The device shall not attempt to transfer more data, this
is a hang condition.
Pat: Please confirm that you understand that this (b) is a
basic requirement for ATA/ATAPI to operate correctly.
c) For read commands the command defines the maximum number of
bytes that the device is allowed to transfer. For MOST read
commands this is the EXACT number of bytes the device SHALL
transfer, plus perhaps a pad byte. Only a FEW read commands,
normally those that have an Allocation Length parameter, are
commands that allow a device to transfer less data, plus perhaps
a pad byte, without indicating an error at the end of the
command. In all cases the host SHALL be prepared to receive the
maximum number of bytes. In PIO and DMA there are no extra or
residue bytes. None, never. The host shall not attempt to stop
the data transfer early, this is a hang condition. It is the
host's problem to determine how many bytes were transferred by
the device.
Pat: Please confirm that you understand that this (c) is a
basic requirement for ATA/ATAPI to operate correctly.
>But let us suppose an Atapi host rudely does ask to copy more
>bytes, at a time when the Atapi device & host do agree over which
>way to copy bytes.
This is an undefined condition and the results are
"indeterminate" (to use a popular word from the ATA/ATAPI-x
documents). In other words, a host that creates this condition
is a BROKEN HOST.
>When copying data via Pio, the device can ask to stop the copy
>at any "byte" boundary.
All DRQ data blocks end at a "word" boundary. The last DRQ data
block may need a a pad byte so that this DRQ data block also ends
at a "word" boundary. Each DRQ data block has a Byte Count (BC).
Using integer arithmetic, the host SHALL transfer (BC+1)/2 words
for every DRQ data block. There is no exception, none, never.
Yes, a host might use an odd value of BC to indicate that there
is a pad byte but this is dangerous because only the command (the
ATAPI PACKET SCSI CDB) actually determines the data transfer
length and therefore only the command should be used to determine
if a pad byte was required by the ATA interface hardware.
>When copying data via SwDma, the device can ask to stop the copy
>at any "word" boundary.
SW DMA is obsolete and not supported by PCI bus systems for
something like 5+ years.
>When copying data via MwDma, T13 allows the device asking to
>stop the copy to be slow. This means our rude host ends up
>copying X extra "word"s, where X may be 0 or 1. In practice,
>people don't make many devices this slow.
There are no extra words or bytes. None, never. This applies to
PIO and DMA (MW and U-DMA) and to write and read data transfer
commands.
>When copying data In via UDma, the device can ask to stop the
>copy at any "word" boundary. Here UDma is as precise as SwDma
>and MwDma in practice, and better than MwDma on paper.
There are no extra words or bytes. None, never. This applies to
PIO and DMA (MW and U-DMA) and to write and read data transfer
commands.
>When copying data Out via UDma, the device the device can ask to
>stop the copy at any "word" boundary, but then the host may send
>another X "word"s. T13 requires the device to ignore these
>"word"s.
There are no extra words or bytes. None, never. This applies to
PIO and DMA (MW and U-DMA) and to write and read data transfer
commands.
** Pat please read the next paragraph! **
Only a BROKEN host, would attempt to send more data to a device
than is required by the command. T13 did not want to make this
failure of a host a condition that must be detected and reported
as an error by a device. But it IS an ERROR condition, it IS a
FAILURE of the host, therefore it IS a BROKEN host. Only a
BROKEN host would create this condition and basically the results
are indeterminate. Actually I would like ATA/ATAPI to say "If
the host attempts to send more data to the device than required
by the write command, the device shall ignore the extra data and
the results of the command execution may be indeterminate."
>If yes, then you understand one part of my proposal: I want us
(T13) to give the device a way t report X for MwDma and UDma.
X is not 0 ONLY when the host or the device is BROKEN. If X is
not 0, then either the host or device is BROKEN. And if the host
or device are broken then the command ends in a hang condition or
with indeterminate results.
I really don't know how many more ways to say all this...
*** Hale Landis *** www.ata-atapi.com ***
