From: Bin Liu <b-liu@ti.com>
To: Vinod Koul <vkoul@kernel.org>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>,
dmaengine@vger.kernel.org, linux-usb@vger.kernel.org,
stable@vger.kernel.org
Subject: dma: cppi41: delete channel from pending list when stop channel
Date: Mon, 26 Nov 2018 07:47:38 -0600 [thread overview]
Message-ID: <20181126134738.GD27653@uda0271908> (raw)
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.
WARNING: multiple messages have this Message-ID (diff)
From: Bin Liu <b-liu@ti.com>
To: Vinod Koul <vkoul@kernel.org>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>,
<dmaengine@vger.kernel.org>, <linux-usb@vger.kernel.org>,
<stable@vger.kernel.org>
Subject: Re: [PATCH] dma: cppi41: delete channel from pending list when stop channel
Date: Mon, 26 Nov 2018 07:47:38 -0600 [thread overview]
Message-ID: <20181126134738.GD27653@uda0271908> (raw)
In-Reply-To: <20181124142803.GI3175@vkoul-mobl.Dlink>
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.
next reply other threads:[~2018-11-26 13:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-26 13:47 Bin Liu [this message]
2018-11-26 13:47 ` [PATCH] dma: cppi41: delete channel from pending list when stop channel Bin Liu
-- strict thread matches above, loose matches on Subject: below --
2018-12-06 14:56 Bin Liu
2018-12-05 8:32 Vinod Koul
2018-11-28 11:16 Peter Ujfalusi
2018-11-28 11:15 Peter Ujfalusi
2018-11-24 14:28 Vinod Koul
2018-11-24 14:28 ` [PATCH] " Vinod Koul
2018-11-12 15:46 Bin Liu
2018-11-12 15:43 Bin Liu
2018-11-12 15:43 ` [PATCH] " Bin Liu
2018-11-12 15:40 Bin Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181126134738.GD27653@uda0271908 \
--to=b-liu@ti.com \
--cc=dmaengine@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=peter.ujfalusi@ti.com \
--cc=stable@vger.kernel.org \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.