Benjamin Herrenschmidt wrote:
quoted text
> 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.  :-)

quoted text
> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/