From: Lars-Peter Clausen <lars@metafoo.de>
To: Robert Baldyga <r.baldyga@samsung.com>, vinod.koul@intel.com
Cc: dan.j.williams@intel.com, dmaengine@vger.kernel.org,
linux-kernel@vger.kernel.org, m.szyprowski@samsung.com,
k.kozlowski@samsung.com
Subject: Re: [PATCH] dmaengine: pl330: get rid of pm_runtime_irq_safe()
Date: Fri, 10 Apr 2015 10:04:08 +0200 [thread overview]
Message-ID: <552783F8.2080506@metafoo.de> (raw)
In-Reply-To: <1428649045-26444-1-git-send-email-r.baldyga@samsung.com>
On 04/10/2015 08:57 AM, Robert Baldyga wrote:
> As using pm_runtime_irq_safe() causes power domain is always enabled,
> we want to get rid of it to reach better power efficiency. For this purpose
> we call pm_runtime_get()/pm_runtime_put() only in DMA channel allocate/free
> code. DMA channels are always requested and freed in non-atomic context,
> so we don't need pm_runtime_irq_safe().
I wonder how useful this is considering that pretty much always a channel is
requested. I think we need an extension to the dmaengine API that allows a
channel consumer to notify the driver that the channel that it requested is
currently not in use. E.g. something like dmaengine_pm_{get,put}(struct
dma_chan *). These functions would have the restriction that they can only
be called from a non-atomic context, whereas issue_pending() and friends can
still be called from a atomic context. So dmaengine_pm_get() would kind of
be a notification that consumer intends to do something in the near future
whereas dmaengine_pm_put() would be a notification that it is not going to
use the channel in the near future.
E.g. for audio DMA the audio driver could call dmaengine_pm_get() when the
PCM device is opened and dmaengine_pm_put() when it is closed. Whereas
issue_pending is called when the audio is started.
- Lars
next prev parent reply other threads:[~2015-04-10 8:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-10 6:57 [PATCH] dmaengine: pl330: get rid of pm_runtime_irq_safe() Robert Baldyga
2015-04-10 7:53 ` Krzysztof Kozlowski
2015-04-10 8:04 ` Lars-Peter Clausen [this message]
2015-04-10 9:57 ` Robert Baldyga
2015-04-10 10:47 ` Lars-Peter Clausen
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=552783F8.2080506@metafoo.de \
--to=lars@metafoo.de \
--cc=dan.j.williams@intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=k.kozlowski@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=r.baldyga@samsung.com \
--cc=vinod.koul@intel.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 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.