From b50102d3e9a43a75379407c2080f696f61cb286b Mon Sep 17 00:00:00 2001 From: Dan Williams Date: Fri, 30 Sep 2011 18:52:19 -0700 Subject: [SCSI] isci: atapi support Based on original implementation from Jiangbi Liu and Maciej Trela. ATAPI transfers happen in two-to-three stages. The two stage atapi commands are those that include a dma data transfer. The data transfer portion of these operations is handled by the hardware packet-dma acceleration. The three-stage commands do not have a data transfer and are handled without hardware assistance in raw frame mode. stage1: transmit host-to-device fis to notify the device of an incoming atapi cdb. Upon reception of the pio-setup-fis repost the task_context to perform the dma transfer of the cdb+data (go to stage3), or repost the task_context to transmit the cdb as a raw frame (go to stage 2). stage2: wait for hardware notification of the cdb transmission and then go to stage 3. stage3: wait for the arrival of the terminating device-to-host fis and terminate the command. To keep the implementation simple we only support ATAPI packet-dma protocol (for commands with data) to avoid needing to handle the data transfer manually (like we do for SATA-PIO). This may affect compatibility for a small number of devices (see ATA_HORKAGE_ATAPI_MOD16_DMA). If the data-transfer underruns, or encounters an error the device-to-host fis is expected to arrive in the unsolicited frame queue to pass to libata for disposition. However, in the DONE_UNEXP_FIS (data underrun) case it appears we need to craft a response. In the DONE_REG_ERR case we do receive the UF and propagate it to libsas. Signed-off-by: Maciej Trela Signed-off-by: Dan Williams Signed-off-by: James Bottomley --- drivers/scsi/isci/request.h | 28 ++++++++++++++++++++++++++-- 1 file changed, 26 insertions(+), 2 deletions(-) (limited to 'drivers/scsi/isci/request.h') diff --git a/drivers/scsi/isci/request.h b/drivers/scsi/isci/request.h index 58d70b6606ef..f720b97b7bb5 100644 --- a/drivers/scsi/isci/request.h +++ b/drivers/scsi/isci/request.h @@ -96,7 +96,6 @@ enum sci_request_protocol { * to wait for another fis or if the transfer is complete. Upon * receipt of a d2h fis this will be the status field of that fis. * @sgl - track pio transfer progress as we iterate through the sgl - * @device_cdb_len - atapi device advertises it's transfer constraints at setup */ struct isci_stp_request { u32 pio_len; @@ -107,7 +106,6 @@ struct isci_stp_request { u8 set; u32 offset; } sgl; - u32 device_cdb_len; }; struct isci_request { @@ -248,6 +246,32 @@ enum sci_base_request_states { */ SCI_REQ_STP_PIO_DATA_OUT, + /* + * While in this state the IO request object is waiting for the TC + * completion notification for the H2D Register FIS + */ + SCI_REQ_ATAPI_WAIT_H2D, + + /* + * While in this state the IO request object is waiting for either a + * PIO Setup. + */ + SCI_REQ_ATAPI_WAIT_PIO_SETUP, + + /* + * The non-data IO transit to this state in this state after receiving + * TC completion. While in this state IO request object is waiting for + * D2H status frame as UF. + */ + SCI_REQ_ATAPI_WAIT_D2H, + + /* + * When transmitting raw frames hardware reports task context completion + * after every frame submission, so in the non-accelerated case we need + * to expect the completion for the "cdb" frame. + */ + SCI_REQ_ATAPI_WAIT_TC_COMP, + /* * The AWAIT_TC_COMPLETION sub-state indicates that the started raw * task management request is waiting for the transmission of the -- cgit v1.2.3