This message is from the T13 list server.
Hale Landis wrote:
Jeff Garzik wrote:
It's more than just that. Given that there is no READ FPDMA nor WRITE
FPDMA commands that are applicable to ATAPI, one would have to
contemplate use of a tagging system buried inside the command set [SCSI].
Hmmm... I don't understand your comment... The tag number is in the
Sector Count register bits 7-3 for R/W DMA QUEUED, PACKET and R/W FPDMA.
Why would the tag need to be inside the PACKET SCSI CDB?
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.
If you think about it the FPDMA command codes were never needed. The
True.
But there is a strong ATA tradition to create
new command codes for minor variations of the same basic command
True. And its a silly tradition.
The PACKET command has never needed all this confusion of multiple
command codes for PIO or DMA or overlap/queuing because the PACKET
command uses the Features register as a way to select protocol and
execution options. So the OVL bit (in the PACKET command Features
register) could be used to select 'ncq' on a SATAPI device. But again,
True.
What do I mean?
The SATA documents, pick one, ATA/ATAPI-7 or the secret society
specification, do not contain the equivalent to the PATA command
protocol state diagrams. The best you can find is ATA/ATAPI-7's Annex J
that is informative. I know a lot of people think the PATA command
protocol state diagrams are used to describe the SATA command protocol
but this is wrong and misleading. SATA is not PATA. SATA is very
[...]
Ultimately, SATA is just a protocol for transporting anonymous data
packets. There, no state diagrams needed...
Jeff
