libata: use ATAPI dma even for data transfers not aligned to 16 bytes

Most ATAPI DMA failures are due to controller issues including choking on data buffer w/o proper padding or draining areas and should be worked around in LLDs. The default 16 byte alignment check in ata_check_atapi_dma() only partially hides problems (well, that was the conclusion back then, at least).

Now that ATAPI DMA support seems fairly stable. Let's take the plunge and verify the previous conclusion was correct.

---
Jeff, Alan, as discussed before, the default 16 byte alignment check doesn't make much sense if our previous conclusion was correct. I guess it's about time we put the theory to the test. It'll be probably best to put this in a separate branch and expose it through -next and -mm only.

Thanks.

 drivers/ata/libata-core.c |    6 ------
 1 file changed, 6 deletions(-)

index 52285f6..0d3d16c 100644
@@ -4325,12 +4325,6 @@ int ata_check_atapi_dma(struct ata_queued_cmd *qc)
 {
 	struct ata_port *ap = qc->ap;
 
-	/* Don't allow DMA if it isn't multiple of 16 bytes.  Quite a
-	 * few ATAPI devices choke on such DMA requests.
-	 */
-	if (unlikely(qc->nbytes & 15))
-		return 1;
-
 	if (ap->ops->check_atapi_dma)
 		return ap->ops->check_atapi_dma(qc);
 

You need to modify some of the drivers before you can remove this check now. At least AMD, and probably nvidia (but who knows) require 4 byte alignment for internal buffering unless you reconfigure the FIFO (actually we should be using inl/outl as well in the AMD case it seems - docs are not 100% clear). I'm currently investigating this bit.

Alan