FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F9.3.0 2014-05-07T16:44:02Z 2014-05-07T16:44:02Z Jim Harris jimharris@FreeBSD.org 2014-05-07T16:44:02Z urn:sha1:548c48db35a038abd9b100f5392551f40b5a80d0 Base the max number of SG elements on MAXPHYS. 2014-05-07T16:43:10Z Jim Harris jimharris@FreeBSD.org 2014-05-07T16:43:10Z urn:sha1:9a840b1bb617b42d78596f40ac2fdc52b5bb927d isci: Ensure ATA passthrough commands with RETURN_RESPONSE bit set translate their response. 2013-11-03T21:12:01Z Jim Harris jimharris@FreeBSD.org 2013-11-03T21:12:01Z urn:sha1:a85819eb83ae30cfecff9fedb274fc81714229d1 Improve logging around some of the isci(4) reset and recovery paths. Sponsored by: Intel 2013-10-14T05:56:15Z Konstantin Belousov kib@FreeBSD.org 2013-10-14T05:56:15Z urn:sha1:8d71ba4809ed6e385982cbefe012c64416f91d8a Make isci(4) loadable. 2013-10-09T19:04:48Z Alexander Motin mav@FreeBSD.org 2013-10-09T19:04:48Z urn:sha1:693bd3e713471b8e40ce420745cc8e98b8b435d1 Fix a bunch of typos. 2013-07-08T15:54:38Z Alexander Motin mav@FreeBSD.org 2013-07-08T15:54:38Z urn:sha1:3e4e5885166ea909e8b4fb152427c50e5d311a22 Stop abusing xpt_periph in random plases that really have no periph related to CCB, for example, bus scanning. NULL value is fine in such cases and it is correctly logged in debug messages as "noperiph". If at some point we need some real XPT periphs (alike to pmpX now), quite likely they will be per-bus, and not a single global instance as xpt_periph now. 2013-07-03T23:29:40Z Jim Harris jimharris@FreeBSD.org 2013-07-03T23:29:40Z urn:sha1:7d1f14b7711931441e7def87f167c3aec85bf92b For ATA_PASSTHROUGH commands, pretend isci(4) supports multiword DMA by treating it as UDMA. This fixes a problem introduced in r249933/r249939, where CAM sends ATA_DSM_TRIM to SATA devices using ATA_PASSTHROUGH_16. scsi_ata_trim() sets protocol as DMA (not UDMA) which is for multi-word DMA, even though no such mode is selected for the device. isci(4) would fail these commands which is the correct behavior but not consistent with other HBAs, namely LSI's. smh@ did some further testing on an LSI controller, which rejected ATA_PASSTHROUGH_16 commands with mode=UDMA_OUT, even though only a UDMA mode was selected on the device. So this precludes adding any kind of mode detection in CAM to determine which mode to use on a per-device basis. Sponsored by: Intel 2013-06-18T05:37:06Z Scott Long scottl@FreeBSD.org 2013-06-18T05:37:06Z urn:sha1:1acae9532fb4692f8a9a27149daf23cbfe65d39c Add unmapped i/o support for the mps and isci drivers. Submitted by: mav, jimharris Obtained from: Netflix 2013-06-18T00:36:53Z Scott Long scottl@FreeBSD.org 2013-06-18T00:36:53Z urn:sha1:039e422c063977ba9073fd2c93883dd8a5a36d48 have been in production at Netflix for several months with significant success. MFC r246713: Reform the busdma API so that new types may be added without modifying every architecture's busdma_machdep.c. It is done by unifying the bus_dmamap_load_buffer() routines so that they may be called from MI code. The MD busdma is then given a chance to do any final processing in the complete() callback. MFC r249538: Some compilers issue a warning when wider integer is casted to narrow pointer. Supposedly shut down the warning by casting through uintptr_t. MFC r251479: Simplify the checking of flags for cam_periph_mapmem(). This gets rid of a lot of code redundancy and grossness at very minor expense. MFC r251837: MFC r251842: Add infrastructure for doing compatibility shims, as has been sorely needed for the last 10 years. Far too much of the internal API is exposed, and every small adjustment causes applications to stop working. To kick this off, bump the API version to 0x17 as should have been done with r246713, but add shims to compensate. Thanks to the shims, there should be no visible change in application behavior. Submitted by: kib, jeffr Approved by: kib Obtained from: Netflix 2012-12-12T00:39:04Z Jim Harris jimharris@FreeBSD.org 2012-12-12T00:39:04Z urn:sha1:da517789ce4b29da240946c19146b0ad15208ea6 Don't call bus_dmamap_load in CAM_DIR_NONE case, since there is nothing to map, and technically this isn't allowed. Functionally, it works OK (at least on x86) to call bus_dmamap_load with a NULL data pointer and zero length, so this is primarily for correctness and consistency with other drivers. While here, remove check in isci_io_request_construct for nseg==0. Previously, bus_dmamap_load would pass nseg==1, even for case where buffer is NULL and length = 0, which allowed CAM_DIR_NONE CCBs to get processed. This check is not correct though, and needed to be removed both for the changes elsewhere in this patch, as well as jeff's preliminary bus_dmamap_load_ccb patch (which uncovered all of this in the first place).