Hi Vinod, On Monday 12 October 2015 20:42:32 Vinod Koul wrote: > On Tue, Sep 29, 2015 at 10:44:46PM +0200, hamzahfrq.sub@xxxxxxxxx wrote: > > From: Muhammad Hamza Farooq <mfarooq@xxxxxxxxxxx> > > > > Signed-off-by: Muhammad Hamza Farooq <mfarooq@xxxxxxxxxxx> > > --- > > > > drivers/dma/sh/rcar-dmac.c | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c > > index 6c806d0..0b5a367 100644 > > --- a/drivers/dma/sh/rcar-dmac.c > > +++ b/drivers/dma/sh/rcar-dmac.c > > @@ -1258,6 +1258,10 @@ static enum dma_status rcar_dmac_tx_status(struct > > dma_chan *chan,> > > residue = rcar_dmac_chan_get_residue(rchan, cookie); > > spin_unlock_irqrestore(&rchan->lock, flags); > > > > + /* if there's no residue, the cookie is complete */ > > + if (!residue) > > + return DMA_COMPLETE; > > + > > why would we get this, you should not be here if the status is complete and > exited before you checked the status The status check is a software check, while the residue check reads hardware registers. The hardware might have complete the transfer but the interrupt handler might not have had a chance to run yet. Is it valid from a DMA engine API point of view to return a DMA_IN_PROGRESS status with a 0 residue ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
