* Grygorii Strashko <grygorii.strashko@xxxxxx> [170113 13:37]:
> > Simplified diff with fix on top of your patch:
> >
> > diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
> > index ce37a1a..9e9403a 100644
> > --- a/drivers/dma/cppi41.c
> > +++ b/drivers/dma/cppi41.c
> > @@ -319,12 +319,6 @@ static irqreturn_t cppi41_irq(int irq, void *data)
> >
> > while (val) {
> > u32 desc, len;
> > - int error;
> > -
> > - error = pm_runtime_get(cdd->ddev.dev);
> > - if ((error != -EINPROGRESS) && (error < 0))
> > - dev_err(cdd->ddev.dev, "%s pm runtime get: %i\n",
> > - __func__, error);
> >
> > /* This warning should never trigger */
> > WARN_ON(cdd->is_suspended);
> > @@ -500,7 +494,6 @@ static void cppi41_dma_issue_pending(struct dma_chan *chan)
> > spin_unlock_irqrestore(&cdd->lock, flags);
> >
> > pm_runtime_mark_last_busy(cdd->ddev.dev);
> > - pm_runtime_put_autosuspend(cdd->ddev.dev);
> > }
> >
> > static u32 get_host_pd0(u32 length)
> >
>
> Ok. this is incorrect in case of USB hub and will just hide the problem
> by incrementing PM runtime usage counter every time USB host is connected :(
Yeah if anything changes in those two nested loops, the pm_runtime counts
get unbalanced.
> Once USB hub is connected the PM runtime usage counter will became 1 and stay
> 1 after disconnection. Which means that some descriptor was pushed in Q, but IRQ
> was not triggered.
>
> Don't know how to proceed as I'm not so familiar with musb :(
I'm now playing with saving the queue manager value and kicking the
PM runtime if we have transfers in progress. Looks like the dma
registers are zero while there are transfers in progress, or at least
I have not yet found any hardware registers that would tell that.
Regards,
Tony
--
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
