From: Robin Gong <yibin.gong@nxp.com>
To: Lucas Stach <l.stach@pengutronix.de>,
Shengjiu Wang <shengjiu.wang@gmail.com>
Cc: "sumit.semwal@linaro.org" <sumit.semwal@linaro.org>,
"linaro-mm-sig@lists.linaro.org" <linaro-mm-sig@lists.linaro.org>,
Linux-ALSA <alsa-devel@alsa-project.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
Timur Tabi <timur@kernel.org>, Xiubo Li <Xiubo.Lee@gmail.com>,
Fabio Estevam <festevam@gmail.com>,
"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
Takashi Iwai <tiwai@suse.com>,
Liam Girdwood <lgirdwood@gmail.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Nicolin Chen <nicoleotsuka@gmail.com>,
Mark Brown <broonie@kernel.org>, dl-linux-imx <linux-imx@nxp.com>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
"perex@perex.cz" <perex@perex.cz>,
"shawnguo@kernel.org" <shawnguo@kernel.org>,
"S.j. Wang" <shengjiu.wang@nxp.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: RE: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
Date: Thu, 22 Apr 2021 03:33:32 +0000 [thread overview]
Message-ID: <VE1PR04MB6688F1C65295C1A0D689C5A289469@VE1PR04MB6688.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <18fbdc4bf0574a722134400ad9e4510d3cbcb767.camel@pengutronix.de>
On 2021/04/22 Lucas Stach <l.stach@pengutronix.de> wrote:
> > But the timer of runtime_auto_suspend decide when enter runtime
> > suspend rather than hardware, while transfer data size and transfer
> > rate on IP bus decide when the dma interrupt happen.
> >
> But it isn't the hardware that decides to drop the rpm refcount to 0 and
> starting the autosuspend timer, it's the driver.
Yes, driver should keep rpm refcount never to 0 in such case. But I think that case
Is a common case in dma cyclic with runtime_auto_suspend, so some dma driver
also add pm_runtime_get_sync/ pm_runtime_put_autosuspend in interrupt handler
like qcom/bam_dma.c for safe rather than only pm_runtime_mark_last_busy().
>
> > Generally, we can call pm_runtime_get_sync(fsl_chan->dev)/
> > pm_runtime_mark_last_busy in interrupt handler to hope the
> > runtime_auto_suspend timer expiry later than interrupt coming, but if
> > the transfer data size is larger in cyclic and transfer rate is very
> > slow like 115200 or lower on uart, the fix autosuspend timer
> > 100ms/200ms maybe not enough, hence, runtime suspend may execute
> > meanwhile the dma interrupt maybe triggered and caught by GIC(but
> > interrupt handler prevent by spin_lock_irqsave in pm_suspend_timer_fn() ),
> and then interrupt handler start to run after runtime suspend.
>
> If your driver code drops the rpm refcount to 0 and starts the autosuspend
> timer while a cyclic transfer is still in flight this is clearly a bug. Autosuspend is
> not there to paper over driver bugs, but to amortize cost of actually
> suspending and resuming the hardware. Your driver code must still work even
> if the timeout is 0, i.e. the hardware is immediately suspended after you drop
> the rpm refcount to 0.
>
> If you still have transfers queued/in-flight the driver code must keep a rpm
> reference.
Yes, that's what I said for fix before as below.
'I have a simple workaround that disable runtime suspend in issue_pending worker by
calling pm_runtime_forbid() and then enable runtime auto suspend in dmaengine_terminate_all
so that we could easily regard that edma channel is always in runtime resume between
issue_pending and channel terminated and ignore the above interrupt handler/scu-pd limitation'
prev parent reply other threads:[~2021-04-22 3:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-19 9:41 [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe Shengjiu Wang
2020-05-19 10:01 ` Lucas Stach
2020-05-20 8:20 ` Shengjiu Wang
2020-05-20 9:42 ` Lucas Stach
2020-05-20 11:22 ` Shengjiu Wang
2020-05-20 12:38 ` Mark Brown
2020-05-21 11:30 ` Shengjiu Wang
2020-05-22 13:12 ` Mark Brown
2021-04-14 14:33 ` Robin Gong
2021-04-14 15:33 ` Lucas Stach
2021-04-19 7:17 ` Robin Gong
2021-04-19 9:46 ` Lucas Stach
2021-04-20 13:47 ` Robin Gong
2021-04-20 14:00 ` Lucas Stach
2021-04-21 14:54 ` Robin Gong
2021-04-21 17:43 ` Lucas Stach
2021-04-21 17:46 ` Mark Brown
2021-04-22 3:33 ` Robin Gong [this message]
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=VE1PR04MB6688F1C65295C1A0D689C5A289469@VE1PR04MB6688.eurprd04.prod.outlook.com \
--to=yibin.gong@nxp.com \
--cc=Xiubo.Lee@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=festevam@gmail.com \
--cc=kernel@pengutronix.de \
--cc=l.stach@pengutronix.de \
--cc=lgirdwood@gmail.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=nicoleotsuka@gmail.com \
--cc=perex@perex.cz \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=shengjiu.wang@gmail.com \
--cc=shengjiu.wang@nxp.com \
--cc=sumit.semwal@linaro.org \
--cc=timur@kernel.org \
--cc=tiwai@suse.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).