From: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: "Rafael J. Wysocki"
<rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>,
Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Laxman Dewangan
<ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Alexandre Courbot
<gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
Date: Fri, 28 Aug 2015 11:30:50 +0100 [thread overview]
Message-ID: <55E0385A.6070203@nvidia.com> (raw)
In-Reply-To: <55DCF056.40004-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On 25/08/15 23:46, Rafael J. Wysocki wrote:
> On 8/25/2015 11:37 AM, Jon Hunter wrote:
[snip]
>> Vinod, thinking about this some more, I am wondering if it is just
>> better to get rid of the suspend/resume callbacks and simply handling
>> the state in the runtime suspend/resume callbacks. I think that would be
>> safe too, because once the clock has been disabled, then who knows what
>> the context state will be.
>
> One caveat here: system suspend may be invoked at any time, so you need
> to ensure that the device is properly suspended when that happens.
>
> I believe you at least need a ->suspend callback for that.
Thanks, makes sense.
On a related note, I see a few drivers, including this DMA driver doing
the following in the driver ->remove callback.
pm_runtime_disable(&pdev->dev);
!pm_runtime_status_suspended(&pdev->dev))
tegra_dma_runtime_suspend(&pdev->dev);
I understand that the code is trying to ensure that the device is
suspended regardless of whether rpm is enabled or not in the kernel
config. However, looking at the pm_runtime_status_suspended() function,
AFAICT, it will always return false above as the disable_depth will be
greater than 0. So I am concerned that the tegra_dma_runtime_suspend()
is called even when not needed? However, I could also be missing
something here.
Cheers
Jon
WARNING: multiple messages have this Message-ID (diff)
From: Jon Hunter <jonathanh@nvidia.com>
To: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Vinod Koul <vinod.koul@intel.com>
Cc: Laxman Dewangan <ldewangan@nvidia.com>,
Stephen Warren <swarren@wwwdotorg.org>,
Thierry Reding <thierry.reding@gmail.com>,
"Alexandre Courbot" <gnurou@gmail.com>,
<dmaengine@vger.kernel.org>, <linux-tegra@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>
Subject: Re: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
Date: Fri, 28 Aug 2015 11:30:50 +0100 [thread overview]
Message-ID: <55E0385A.6070203@nvidia.com> (raw)
In-Reply-To: <55DCF056.40004@intel.com>
On 25/08/15 23:46, Rafael J. Wysocki wrote:
> On 8/25/2015 11:37 AM, Jon Hunter wrote:
[snip]
>> Vinod, thinking about this some more, I am wondering if it is just
>> better to get rid of the suspend/resume callbacks and simply handling
>> the state in the runtime suspend/resume callbacks. I think that would be
>> safe too, because once the clock has been disabled, then who knows what
>> the context state will be.
>
> One caveat here: system suspend may be invoked at any time, so you need
> to ensure that the device is properly suspended when that happens.
>
> I believe you at least need a ->suspend callback for that.
Thanks, makes sense.
On a related note, I see a few drivers, including this DMA driver doing
the following in the driver ->remove callback.
pm_runtime_disable(&pdev->dev);
!pm_runtime_status_suspended(&pdev->dev))
tegra_dma_runtime_suspend(&pdev->dev);
I understand that the code is trying to ensure that the device is
suspended regardless of whether rpm is enabled or not in the kernel
config. However, looking at the pm_runtime_status_suspended() function,
AFAICT, it will always return false above as the disable_depth will be
greater than 0. So I am concerned that the tegra_dma_runtime_suspend()
is called even when not needed? However, I could also be missing
something here.
Cheers
Jon
next prev parent reply other threads:[~2015-08-28 10:30 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-18 13:49 [RFC PATCH 0/7] DMA: Add support for Tegra210 ADMA Jon Hunter
2015-08-18 13:49 ` Jon Hunter
[not found] ` <1439905755-25150-1-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-08-18 13:49 ` [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage Jon Hunter
2015-08-18 13:49 ` Jon Hunter
2015-08-23 14:17 ` Vinod Koul
2015-08-24 8:47 ` Jon Hunter
2015-08-24 8:47 ` Jon Hunter
2015-08-24 9:22 ` Vinod Koul
2015-08-24 13:22 ` Jon Hunter
2015-08-24 13:22 ` Jon Hunter
[not found] ` <55DB1AA9.7090906-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-08-24 14:21 ` Vinod Koul
2015-08-24 14:21 ` Vinod Koul
2015-08-25 0:04 ` Rafael J. Wysocki
[not found] ` <13590312.K3yoQT5YDc-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>
2015-08-25 9:37 ` Jon Hunter
2015-08-25 9:37 ` Jon Hunter
2015-08-25 22:46 ` Rafael J. Wysocki
[not found] ` <55DCF056.40004-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-08-28 10:30 ` Jon Hunter [this message]
2015-08-28 10:30 ` Jon Hunter
2015-08-18 13:49 ` [RFC PATCH 2/7] DMA: tegra-apb: Move code dealing with h/w registers into separate functions Jon Hunter
2015-08-18 13:49 ` Jon Hunter
2015-08-18 13:49 ` [RFC PATCH 5/7] DMA: tegra-apb: Move common code into separate source files Jon Hunter
2015-08-18 13:49 ` Jon Hunter
2015-08-18 13:49 ` [RFC PATCH 6/7] Documentation: DT: Add binding documentation for NVIDIA ADMA Jon Hunter
2015-08-18 13:49 ` Jon Hunter
2015-08-18 13:49 ` [RFC PATCH 7/7] DMA: tegra-adma: Add support for Tegra210 ADMA Jon Hunter
2015-08-18 13:49 ` Jon Hunter
[not found] ` <1439905755-25150-8-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-08-23 14:33 ` Vinod Koul
2015-08-23 14:33 ` Vinod Koul
2015-08-24 8:55 ` Jon Hunter
2015-08-24 8:55 ` Jon Hunter
2015-08-24 9:24 ` Vinod Koul
2015-08-18 13:49 ` [RFC PATCH 3/7] DMA: tegra-apb: Clean-up and simplify setting up of transfer parameters Jon Hunter
2015-08-18 13:49 ` Jon Hunter
2015-08-18 13:49 ` [RFC PATCH 4/7] DMA: tegra-apb: Add a function table for functions dealing with registers Jon Hunter
2015-08-18 13:49 ` Jon Hunter
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=55E0385A.6070203@nvidia.com \
--to=jonathanh-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
--cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.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.