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