From: Vinod Koul <vkoul@kernel.org>
To: Jon Hunter <jonathanh@nvidia.com>
Cc: "Dmitry Osipenko" <digetx@gmail.com>,
"Laxman Dewangan" <ldewangan@nvidia.com>,
"Dan Williams" <dan.j.williams@intel.com>,
"Thierry Reding" <thierry.reding@gmail.com>,
"Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
dmaengine@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 09/13] dmaengine: tegra-apb: Remove runtime PM usage
Date: Fri, 10 Jan 2020 13:35:10 +0530 [thread overview]
Message-ID: <20200110080510.GH2818@vkoul-mobl> (raw)
In-Reply-To: <01660250-0489-870a-6f0e-d74c5041e8e3@nvidia.com>
On 07-01-20, 18:38, Jon Hunter wrote:
>
> On 07/01/2020 17:12, Dmitry Osipenko wrote:
> > 07.01.2020 18:13, Jon Hunter пишет:
> >>
> >> On 06/01/2020 01:17, Dmitry Osipenko wrote:
> >>> There is no benefit from runtime PM usage for the APB DMA driver because
> >>> it enables clock at the time of channel's allocation and thus clock stays
> >>> enabled all the time in practice, secondly there is benefit from manually
> >>> disabled clock because hardware auto-gates it during idle by itself.
> >>
> >> This assumes that the channel is allocated during a driver
> >> initialisation. That may not always be the case. I believe audio is one
> >> case where channels are requested at the start of audio playback.
> >
> > At least serial, I2C, SPI and T20 FUSE are permanently keeping channels
> > allocated, thus audio is an exception here. I don't think that it's
> > practical to assume that there is a real-world use-case where audio
> > driver is the only active DMA client.
> >
> > The benefits of gating the DMA clock are also dim, do you have any
> > power-consumption numbers that show that it's really worth to care about
> > the clock-gating?
>
> No, but at the same time, I really don't see the point in this. In fact,
> I think it is a step backwards. If we wanted to only enable clocks while
> DMA channels are active we could. So I request you drop this.
Agree, if pm is working fine with audio, doesnt make much sense to
remove. Future clients or updates to existing clients can be done to
make it dynamic..
--
~Vinod
next prev parent reply other threads:[~2020-01-10 8:05 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-06 1:16 [PATCH v3 00/13] NVIDIA Tegra APB DMA driver fixes and improvements Dmitry Osipenko
2020-01-06 1:16 ` [PATCH v3 01/13] dmaengine: tegra-apb: Fix use-after-free Dmitry Osipenko
2020-01-06 1:16 ` [PATCH v3 02/13] dmaengine: tegra-apb: Implement synchronization callback Dmitry Osipenko
2020-01-06 1:16 ` [PATCH v3 03/13] dmaengine: tegra-apb: Prevent race conditions on channel's freeing Dmitry Osipenko
2020-01-06 1:16 ` [PATCH v3 04/13] dmaengine: tegra-apb: Clean up tasklet releasing Dmitry Osipenko
2020-01-06 1:17 ` [PATCH v3 05/13] dmaengine: tegra-apb: Prevent race conditions of tasklet vs free list Dmitry Osipenko
2020-01-06 1:17 ` [PATCH v3 06/13] dmaengine: tegra-apb: Use devm_platform_ioremap_resource Dmitry Osipenko
2020-01-06 1:17 ` [PATCH v3 07/13] dmaengine: tegra-apb: Use devm_request_irq Dmitry Osipenko
2020-01-06 1:17 ` [PATCH v3 08/13] dmaengine: tegra-apb: Fix coding style problems Dmitry Osipenko
2020-01-06 1:17 ` [PATCH v3 09/13] dmaengine: tegra-apb: Remove runtime PM usage Dmitry Osipenko
2020-01-07 15:13 ` Jon Hunter
2020-01-07 15:13 ` Jon Hunter
2020-01-07 17:12 ` Dmitry Osipenko
2020-01-07 18:38 ` Jon Hunter
2020-01-07 18:38 ` Jon Hunter
2020-01-08 15:10 ` Dmitry Osipenko
2020-01-10 8:05 ` Vinod Koul [this message]
2020-01-06 1:17 ` [PATCH v3 10/13] dmaengine: tegra-apb: Clean up suspend-resume Dmitry Osipenko
2020-01-06 1:17 ` [PATCH v3 11/13] dmaengine: tegra-apb: Add missing of_dma_controller_free Dmitry Osipenko
2020-01-06 1:17 ` [PATCH v3 12/13] dmaengine: tegra-apb: Allow to compile as a loadable kernel module Dmitry Osipenko
2020-01-06 1:17 ` [PATCH v3 13/13] dmaengine: tegra-apb: Remove MODULE_ALIAS Dmitry Osipenko
2020-01-08 12:51 ` [PATCH v3 00/13] NVIDIA Tegra APB DMA driver fixes and improvements Thierry Reding
2020-01-08 15:07 ` Dmitry Osipenko
2020-01-09 10:04 ` Thierry Reding
2020-01-09 10:04 ` Thierry Reding
2020-01-09 14:24 ` Dmitry Osipenko
2020-01-09 14:24 ` Dmitry Osipenko
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=20200110080510.GH2818@vkoul-mobl \
--to=vkoul@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=digetx@gmail.com \
--cc=dmaengine@vger.kernel.org \
--cc=jonathanh@nvidia.com \
--cc=ldewangan@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mirq-linux@rere.qmqm.pl \
--cc=thierry.reding@gmail.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.