On Wed, Apr 20, 2011 at 6:29 PM, Linus Walleij [off-list ref] wrote:

On Tue, Apr 19, 2011 at 2:03 PM, Russell King - ARM Linux
[off-list ref] wrote:

quoted

On Tue, Apr 19, 2011 at 02:00:17PM +0200, Linus Walleij wrote:

quoted

On a high-speeded ux500 the DATAEND IRQ will assert before the
DMA data is actually finished, thus if we start hammering in the next
request we break an ongoing transfer. :-(

Yes, you've already said that in the past. ?And this is partly why we
have this code in the dma unmap:

? ? ? ?/* Wait up to 1ms for the DMA to complete */
? ? ? ?for (i = 0; ; i++) {
? ? ? ? ? ? ? ?status = readl(host->base + MMCISTATUS);
? ? ? ? ? ? ? ?if (!(status & MCI_RXDATAAVLBLMASK) || i >= 100)
? ? ? ? ? ? ? ? ? ? ? ?break;
? ? ? ? ? ? ? ?udelay(10);
? ? ? ?}

So, we wait until the DMA has drained the FIFO before we fire off the
next request - or even unmap the DMA buffer. ?Should the DMA fail to
drain the FIFO in a reasonable time, we timeout and disable DMA.

Again, I ask, why is this not sufficient to cover the case where the
data end IRQ occurs before the DMA engine has completed the transfer -
which is likely to take a very short time indeed.

It doesn't help, we have really tested this and at high speed transfers
(especially if we use Per Fridens speed-up patches) apparently
the flag RXDATAAVLBL goes to zero before the block is really
finished.

I haven't really done any specific testing on this. Ulf has reproduced
it without my "speed-up" patches an old version of mmci before the DMA
was in mainline, not sure if it's done on the current mmci. I run data
test (dt) for hours without running into this. But my main concern is
more about verifying the changes I make in the mmc framework by
running cross platform tests (u8500, u5500, pandaboard ...). My focus
hasn't been about testing potential race conditions in the mmci driver
on ux500. I am willingly to test this dma race condition if there are
any doubts whether it still exists or not.

Yours,
Linus Walleij

Regards,
Per