Re: [PATCH] dmaengine: cppi41: Fix cppi41_dma_prep_slave_sg() when idle

[Tony Lindgren <tony@atomide.com>]

* Peter Ujfalusi <peter.ujfalusi@ti.com> [191023 19:55]:
> On 10/23/19 10:18 PM, Tony Lindgren wrote:
> > We'd have to allow dma consumer driver call pm_runtime_get_sync()
> > on the dma device. Something similar maybe to what we have
> > for phy_pm_runtime_get_sync(). Or just get the device handle for
> > dma so the consumer can call pm_runtime_get_sync() on it.
> 
> How much a pm_runtime_get_sync(dmadev) is different when it is issued by
> the client driver compared to when the dma driver issues it for it's own
> device?

Well the consumer device could call pm_runtime_get_sync(dmadev)
when the USB cable is connected for example, and then call
pm_runtime_pu(dmadev) when let's say the USB cable is disconnected.

Without using pm_runtime_irq_safe() we currently don't have a
clear path for doing this where the pm_runtime_get_sync(dmadev)
may sleep.

> But I still fail to see the difference between the events before this
> patch and with the case when there is a 100ms delay between prep_sg and
> issue_pending.
> 
> Before this patch:
> 
> prep_sg()
> issue_pending() <- runtime_get() /  put_autosuspend()
> 		   _not_ starting transfer
> runtime_resume() <- starts the transfer
> 
> With this patch and than 100ms delay between prep_sg and issue_pending:
> 
> prep_sg() <- runtime_get() /  put_autosuspend()
> runtime_resume() <- not starting transfer
> issue_pending() <- runtime_get() /  put_autosuspend()
> 		   starts the transfer
> 
> With this patch, but more than 100ms delay in between:
> 
> prep_sg() <- runtime_get() /  put_autosuspend()
> runtime_resume() <- not starting transfer
> > 100ms delay
> runtime_suspend()
> issue_pending() <- runtime_get() /  put_autosuspend()
> 		   _not_ starting transfer
> runtime_resume() <- starts the transfer
> 
> pm_runtime_get_sync() in issue_pending would be the solution to avoid
> delayed execution, but the usb driver should not assume that DMA is
> completed as soon as issue_pending returned.

Oh I see. Yes the consumer driver would need to check for
the completed dma transfer in all cases. The delay issues
should not currently happen in the musb_ep_program() problem
case as it gets called from IRQ context.

And no, adding pm_runtime_get_sync() to issue_pending is not
a solution. There may be clocks and regulators that need to
be powered up, and we don't want to use pm_runtime_irq_safe()
because of the permanent use count on the parent.

Regards,

Tony