On Mon, Jan 04, 2010 at 10:25:37AM -0500, Jeff Garzik wrote: > On 01/04/2010 08:30 AM, Russell King wrote: >> This rather makes sense. The PDC20247 handles the UDMA part of the >> protocol. It has no way to tell the PDC20246 to wait while it suspends >> UDMA, so that a normal register access can take place - the 246 ploughs >> on with the register access without any regard to the state of the 247. >> >> If the drive immediately starts the UDMA protocol after a write to the >> command register (as it probably will for the DMA WRITE command), then >> we'll be accessing the taskfile in the middle of the UDMA setup, which >> can't be good. It's certainly a violation of the ATA specs. > > Well... > > Without AltStatus, you would not be able to check and see if a command > is complete... I wasn't inferring that reading altstatus was a bad idea. I was saying that causing altstatus to be read in the middle of an active UDMA transfer (in other words, while the hosts DMACK is active) is a violation of the spec. There's no way for the 20247 (UDMA add-on) to know that the IO access is coming; the first the 247 knows about it is when the CS/address lines to the drive have been activated - in violation of the ATA specification (which calls for the CS lines to be inactive and address lines to be zero while UDMA is occuring.) That means there's absolutely no way for the 20247 to stop the UDMA protocol to allow a read of any registers on the drive until UDMA has completed. Yes, technically a buggy host design... -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- 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
