Hi Arnd, On Wed, Feb 16, 2011 at 04:59:18PM +0100, Arnd Bergmann wrote: > 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. > The only thing we actually put in tasklet is just the callback registered by client device driver, which should not have anything that mxs_dma_tx_submit would concern. > 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. > I'm not sure that I understand your comment. If the adding/removing an element means what mxs_dma_alloc_chan_resources and mxs_dma_free_chan_resources do, I do not think it's a problem, as client driver is calling them in probe/remove for once. -- Regards, Shawn -- 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
