WIP: ATA to CAM integration
Matthew Dillon
dillon at apollo.backplane.com
Sat Jun 6 23:33:20 UTC 2009
I found the ATAPI_C_ATAPI_IDENTIFY command that was mentioned and it
works fine, returning the same sort of information for ATAPI attachments
that ATA_C_IDENTIFY returns for DISK attachments.
That takes care of the queue length negotiation by the device.
However, there is no fis->command that I can find that would allow
NCQ to operate in ATAPI mode. In ATAPI mode fis->command is typically
set to ATA_C_PACKET. In DISK mode fis->command is set to
ATA_C_READ_FPDMA or ATA_C_WRITE_FPDMA (the first-person DMA mode used
by AHCI's NCQ).
So unless the *_FPDMA FIS commands work for an ATAPI attached device,
we are S.O.L.
Section 5.6.4.1:
The ATA/ATAPI-7 queued feature set is not supported by AHCI (including
READ QUEUED (EXT), WRITE QUEUED (EXT), and SERVICE commands). Queued
operations are supported in AHCI using the READ FPDMA QUEUED and
WRITE FPDMA QUEUED commands when the HBA and device support native
command queueing.
It is unclear whether an ATAPI device would accept a non-packet command,
aka ATA_C_READ_FPDMA or ATA_C_WRITE_FPDMA, instead of ATA_C_PACKET.
ATAPI devices do support the ATAPI_C_ATAPI_IDENTIFY command, which
is non-packet command, so maybe its possible.
If it is possible it would only work for READ and WRITE commands,
since those are the only commands the FPDMA modes can be used for.
The AHCI spec doesn't explicitly say that the FPDMA commands would not
work for an ATAPI attached device, so there's hope. What we need is
a SATA ATAPI device which says it supports NCQ + has a queue
length > 1 to test with.
-Matt
Matthew Dillon
<dillon at backplane.com>
More information about the freebsd-current
mailing list