Benjamin Herrenschmidt wrote: > Am I the only one to find Pavel variant almost as obscure as > the original one ? :-) > > It should explain precisely what the workaround is. Ie. to start the > DMA there instead of where it normally is started which is the > bmdma_setup() function. Well, it's better than the original which kind of directed the other way. :-) > BTW. Tejun, I suppose that usually starting DMA after issuing the > command is a standard practice of legacy/sff type controllers ? Or it's > just because that's how linux did it until now ? It's how the standard says it should be programmed. Please take a look at section 3 of the following document. http://www.centrillium-it.com/Projects/idems100.pdf It's a non-issue for PATA ones as the host is responsible for running the clock and transferring data after the drive indicated readiness, so the worst that can happen by starting the dma engine after issuing the command is the drive waiting in ready state. For SATA, it should work the same. The host should hold the transfer by not acking the data transfer request (or prefetch the data if it feels smart and brave). So, it's something sata_svw screwed up. -- tejun -- 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
