1. 02 Oct, 2011 2 commits
    • Dan Williams's avatar
      [SCSI] isci: atapi support · b50102d3
      Dan Williams authored
      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
      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: default avatarMaciej Trela <maciej.trela@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
    • Dan Williams's avatar
      [SCSI] isci: fix support for large smp requests · 54b5e3a4
      Dan Williams authored
      Kill the local smp response buffer.
      Besides being unnecessary, it is too small (currently truncates
      responses to 60 bytes).  The mid-layer will have already allocated a
      sufficiently sized buffer, just kmap and copy into it directly.
      Cc: <stable@kernel.org>
      Reported-by: default avatarDerick Marks <derick.w.marks@intel.com>
      Tested-by: default avatarDerick Marks <derick.w.marks@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
  2. 23 Aug, 2011 2 commits
  3. 03 Jul, 2011 36 commits