Alan Cox wrote:
On Thu, 24 May 2007 06:52:13 -0400
Jeff Garzik <jgarzik@xxxxxxxxx> wrote:
Alan Cox wrote:
Currently libata does the 400ns thingy in the inline ata_pause() which
unconditionally does ata_altstatus(); ndelay(400); (and thus does it on
PIO, MMIO, anything ...).
It might actually improve performance for PATA if we did as we'll get rid
of an excess (expensive) PCI read access for non MMIO cases.
The spec says you should read AltStatus. I am definitely not inclined
to change that part.
Which spec says that and where ?
Found it! It was in the spec I consider more authoritative than any
official ATA spec: Hale Landis' ATADRVR (http://www.ata-atapi.com/):
// This macro provides a small delay that is used in several
// places in the ATA command protocols:
// 1) It is recommended that the host delay 400ns after
// writing the command register.
// 2) ATA-4 has added a new requirement that the host delay
// 400ns if the DEV bit in the Device/Head register is
// changed. This was not recommended or required in ATA-1,
// ATA-2 or ATA-3. This is the easy way to do that since it
// works in all PIO modes.
// 3) ATA-4 has added another new requirement that the host delay
// after the last word of a data transfer before checking the
// status register. This was not recommended or required in
// ATA-1, ATA-2 or ATA-3. This is the easy to do that since it
// works in all PIO modes.
#define DELAY400NS { pio_inbyte( CB_ASTAT ); pio_inbyte( CB_ASTAT ); \
pio_inbyte( CB_ASTAT ); pio_inbyte( CB_ASTAT ); }
libata was originally written by following ATADRVR IO-for-IO. You can
still see some of the mostly-unmodified bitbang sequences in
libata-core.c in places like dev-select or dev-chk. Sometimes you have
to look pretty hard, since hooks make the bitbang sequences much harder
to follow.
Obviously libata's "pause" differs from Hale's version a bit, but the
basic version is sound and works for everybody from ancient PATA PIO to
modern SATA MMIO.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
