Re: [PATCH RESEND number 2] libata: eliminate the home grown dma padding in favour of that provided by the block layer

Jeff Garzik
2008-02-03T16:38:58Z

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