> Without AltStatus, you would not be able to check and see if a command > is complete... pretty much by definition you should able to access that Correct - and you may not make that check for 400nS after the command is issued. The old IDE code enforces this (I know because I added it to fix real problems as PC's got fast enough to go from write to IRQ in 400nS) > It is certainly conceivable that this is a problem on a rare controller > or two, but in general, AltStatus is how you poll for DMA completion. > You are allowed to hit it during a DMA transfer. But not for 400nS after a command is issued, or on certain old controllers during a DMA transfer before you halt it. > HOWEVER, accessing AltStatus prior to the 400ns post-exec-command period > is potentially an area of undefined behavior. Changing this code is > only a problem for MMIO-based controllers, which use the AltStatus read > to guarantee that the 400ns delay occurs outside any posted writes. Certainly for pio interfaces we should use ndelay(400). All our MMIO controllers are SATA and that's a different world anyway, including the fact that an altstatus read isn't going to produce a timing delay ! Basically we know ndelay(400) works. SIL680 is MMIO in the old IDE stack but the hardware appears to be doing the required magic itself. In fact as it can stack two commands in non LBA48 mode (a feature we don't use) it would seem to have a fairly complete internal state machine. Alan -- 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
