]> pilppa.com Git - linux-2.6-omap-h63xx.git/commitdiff
libata-sff: Fix documentation
authorAlan Cox <alan@lxorguk.ukuu.org.uk>
Thu, 20 Sep 2007 14:03:07 +0000 (15:03 +0100)
committerJeff Garzik <jeff@garzik.org>
Thu, 20 Sep 2007 19:58:26 +0000 (15:58 -0400)
Code moved to ioread/iowrite but the comment didn't
Also note a posting issue

Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
drivers/ata/libata-sff.c

index 1cce2198baaf1203deb7e1e7e6df305e215501df..8023167bbbeb68623fd9939887010fb74362cb70 100644 (file)
@@ -297,7 +297,7 @@ void ata_bmdma_start (struct ata_queued_cmd *qc)
        dmactl = ioread8(ap->ioaddr.bmdma_addr + ATA_DMA_CMD);
        iowrite8(dmactl | ATA_DMA_START, ap->ioaddr.bmdma_addr + ATA_DMA_CMD);
 
-       /* Strictly, one may wish to issue a readb() here, to
+       /* Strictly, one may wish to issue an ioread8() here, to
         * flush the mmio write.  However, control also passes
         * to the hardware at this point, and it will interrupt
         * us when we are to resume control.  So, in effect,
@@ -307,6 +307,9 @@ void ata_bmdma_start (struct ata_queued_cmd *qc)
         * is expected, so I think it is best to not add a readb()
         * without first all the MMIO ATA cards/mobos.
         * Or maybe I'm just being paranoid.
+        *
+        * FIXME: The posting of this write means I/O starts are
+        * unneccessarily delayed for MMIO
         */
 }