Hi Arnd,

On Wed, Feb 16, 2011 at 04:59:18PM +0100, Arnd Bergmann wrote:

On Wednesday 16 February 2011, Shawn Guo wrote:

quoted

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