On Mon, Jan 04, 2010 at 10:32:55AM -0500, Jeff Garzik wrote: > On 01/04/2010 10:16 AM, Alan Cox wrote: >>> 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. >> >> I concur entirely - that wants pushing into the upstream kernel ASAP and >> if its ok backporting. May also be worth seeing if that fixes the funny >> in the ALi setup. > > How do you think one tests for command completion? :) There does not > seem to be a general problem reading AltStatus(BSY) during a DMA > transfer. IDE driver and other well known codebases have been doing > that for decades. > > I think the undefined behavior is only where the AltStatus read occurs > before the 400ns period specified by ATA... excising the AltStatus read > there (ata_sff_pause) should be fine for PIO, but problematic for MMIO > chipsets that need posted writes flushed prior to the 400ns delay. That's not the problem here - with the printk's I've added, there's no way for the IO read/writes to come that fast. Slowing down the IO accesses made no difference what so ever. -- 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
