[v3 1/2] dma: mmp_pdma: add support for residue reporting
zonque at gmail.com
Fri Aug 16 11:40:06 EDT 2013
On 16.08.2013 09:57, Xiang Wang wrote:
> On 08/15/2013 12:19 AM, Daniel Mack wrote:
>> In order to report the channel's residue, we have to memorize the first
>> dma buffer position when the channel is configured.
>> Signed-off-by: Daniel Mack <zonque at gmail.com>
>> drivers/dma/mmp_pdma.c | 45 +++++++++++++++++++++++++++++++++++++++++++--
>> 1 file changed, 43 insertions(+), 2 deletions(-)
>> +static unsigned int mmp_pdma_residue(struct mmp_pdma_chan *chan)
>> + struct mmp_pdma_desc_sw *sw;
>> + u32 curr, done = 0;
>> + if (chan->dir == DMA_DEV_TO_MEM)
>> + curr = readl(chan->phy->base + DTADR(chan->phy->idx));
> One concern for this patch:
> If we call dmaengine_tx_status() after dma_do_tasklet at mmp_pdma.c,
> chan->phy will most likely to be NULL.
> dma_do_tasklet() -> start_pending_queue() -> mmp_pdma_free_phy()
Yes, I noticed this, too. I'm not really sure what the reason is to call
start_pending_queue() _before_ the callbacks are done. A quick test
shows that it works as well the other way around.
> For why do we call dmaengine_tx_status() after a DMA interrupt:
> briefly, if we use DMA to handle device trailing bytes, it'll report a
> DMA interrupt. We need to get to know how many bytes have been received
> in the IRQ handler.
> We've discussed about this in the link below:
Thanks for the link, I wasn't aware of that discussion. And I actually
second what Andy said: As long as the residue calculation algorithm can
cope with the chan->phy==NULL condition and return 0 in that case, it's
actually doing the right thing, because a completed transaction has a
residue of 0 bytes.
I'll send out another series later, that also aims to fix the tasklet
behaviour. I'd appreciate another round of reviews :)
More information about the linux-arm-kernel