This message is from the T13 list server.
Hale Landis wrote:
This message is from the T13 list server.
Jeff Garzik wrote:
This message is from the T13 list server.
More generally, there is an inherent conflict between ATA queueing and
queueing that's already defined by the command set.
If we are to support ATAPI NCQ, I would think that would involve some
amount of coupling inside the device firmware between the ATA and SCSI
command responses, and behaviors.
meetings? If so, sorry.) What is the "inherent conflict" - a PACKET
command using NCQ is no different than a R/W FPDMA command - The command
and command parameters including the tag number are sent to the device,
the device transfers data using SATA NCQ data transfer protocol. And of
course this would require new firmware in SATAPI devices. What
additional "coupling" is required beyond what is there today in an ATAPI
device?
If the underlying command set doesn't handle queuing, then you don't get
a whole lot of useful queueing. In the standard command set (sidebar:
why is ATA/ATAPI so vague about calling it SCSI?), SCSI, there is some
notion of task [queue] management.
Ultimately, SATA is just a protocol for transporting anonymous data
packets. There, no state diagrams needed...
So on a SATA interface command packets, status packets and data packets
can be sent in any order at any time by host or device? If that is so
Pretty much, yes. Example: one could program the device, and the host
controller, to converse 100% in app-specific frames (FIS's).
In practice, that doesn't happen, but FIS-based host controllers support
support the concept of "unknown FIS", which means the device sent the
host something totally weird... or app-specific.
Certainly there are specific state sequences considered to be standard
SATA, for the purpose of ATA command protocol(s) execution, but the
underlying technology is nothing but a packet-shuffling point-to-point
network link.
Jeff
