James Bottomley wrote:
The aic94xx sequencer has a very finely honed sense of DMA transfers. It's fully automated, and handles both ATA DMA and ATA PIO in the sequencer engine (so all the driver sees is DMA).
ditto AHCI, and most other DMA engines
It reports both underrun and overrun conditions. For DMA underrun
ditto AHCI, and most other DMA engines
(device transfers less than expected, it just returns what it has and how much was missing as the residual) for DMA overrun (as in device tried to take more than it was programmed to send on either read or write) for PIO it does seem to zero fill or discard and then simply report task complete with overrun and let libsas sort it out. I suspect for DMA it first tries DMAT before taking other actions, but I'd need a protocol analyser (or the sequencer docs) to be sure.
Almost every other DMA engine on the planet besides aic94xx is pretty much the same... you set up an s/g tables, and it reports overrun or underrun via an interrupt + status register bit.
It sounds like aic94xx might do more work in the firmware -- that counts as "advanced", since some of the DMA engine cleanup clearly occurs in firmware, rather than pushed to kernel software.
Nowhere do I see anything about AHCI that is "broken." It has standard DMA engine behavior found in storage and non-storage hardware.
We handle overruns as error conditions in both SAS and ATA at the moment, but the point is that the ATAPI device is fully happy and quiesced when we do this.
That may be the result of aic94xx handling extra FIS's in the firmware, something we cannot depend on for purely silicon-based devices.
mvsas, broadsas, ahci, sata_sil24, and others behave similarly... Please don't mistake lack of firmware cleanup as "broken hardware."
Jeff - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
