On Wednesday 16 February 2011, Shawn Guo wrote: > It's caused by spinlock recursion introduced by mxs-dma functions > mxs_dma_tx_submit and mxs_dma_tasklet. We have mmc_request_done > invoked in the dma callback tasklet. At the meantime, > mmc_request_done will issue retries in some case, which will call in > mxs_dma_tx_submit. > > I added the lock by referring to other dma driver implementation, but > now I'm considering to remove the lock completely, as I do not see > any global data needs to be protected there. Comments? You need to be sure that the data accessed in the tasklet does not need to be locked against mxs_dma_tx_submit. I haven't looked at the dmaengine code for this, but it's quite likely that you actually need it, because you need to serialize adding an element to the DMA device with removing it again. Also, since the lock is taken in a tasklet, every thread that takes it outside of a tasklet must do spin_lock_bh(), not spin_lock(), to prevent the tasklet from running. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
