Hi, On Sat, Nov 24, 2018 at 07:58:03PM +0530, Vinod Koul wrote: > On 12-11-18, 09:43, Bin Liu wrote: > > The driver defines three states for a cppi channel. > > - idle: .chan_busy == 0 && not in .pending list > > - pending: .chan_busy == 0 && in .pending list > > - busy: .chan_busy == 1 && not in .pending list > > > > There are cases in which the cppi channel could be in the pending state > > when cppi41_dma_issue_pending() is called after cppi41_runtime_suspend() > > is called. > > > > cppi41_stop_chan() has a bug for these cases to set channels to idle state. > > It only checks the .chan_busy flag, but not the .pending list, then later > > when cppi41_runtime_resume() is called the channels in .pending list will > > be transitioned to busy state. > > > > Removing channels from the .pending list solves the problem. > > I would like some testing, given that intent is to go to stable. > Peter..? FYI, this cppi41 dma driver is *only* used by musb controller driver. In the past I received multiple reports for this issue, but I wasn't able to reproduce it using similar test cases. The only way I could trigger the issue is to do system suspend/resume test on AM335x with a USB hub attached to the usb host port. This issue only happens once in the very *first* time suspend/resume test after reboot. Regards, -Bin.
