linux-tegra.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  parent reply	other threads:[~2015-08-28 10:30 UTC|newest]

Thread overview: 20+ 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 ` [RFC PATCH 3/7] DMA: tegra-apb: Clean-up and simplify setting up of transfer parameters 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
     [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-23 14:17     ` Vinod Koul
2015-08-24  8:47       ` Jon Hunter
2015-08-24  9:22         ` Vinod Koul
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-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 22:46                       ` Rafael J. Wysocki
     [not found]                         ` <55DCF056.40004-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-08-28 10:30                           ` Jon Hunter [this message]
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   ` [RFC PATCH 5/7] DMA: tegra-apb: Move common code into separate source files 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   ` [RFC PATCH 7/7] DMA: tegra-adma: Add support for Tegra210 ADMA 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-24  8:55         ` Jon Hunter
2015-08-24  9:24           ` Vinod Koul

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 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).