mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Kevin Hilman <khilman@kernel.org>, Vinod Koul <vinod.koul@intel.com>
Cc: Jon Hunter <jonathanh@nvidia.com>,
	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
Subject: Re: [PATCH 1/6] dmaengine: tegra-apb: Correct runtime-pm usage
Date: Thu, 05 Nov 2015 03:15:18 +0100	[thread overview]
Message-ID: <1564097.buIA8Wdn8f@vostro.rjw.lan> (raw)
In-Reply-To: <7hvb9hr98g.fsf@deeprootsystems.com>

On Wednesday, November 04, 2015 08:59:43 AM Kevin Hilman wrote:
> Vinod Koul <vinod.koul@intel.com> writes:
> 
> > On Tue, Nov 03, 2015 at 01:25:09PM -0800, Kevin Hilman wrote:
> >> >>>>>  	/* Enable clock before accessing register */
> >> >>>>> -	ret = tegra_dma_runtime_resume(dev);
> >> >>>>> +	ret = pm_runtime_get_sync(dev);
> >> >>>>
> >> >>>> If you are runtime suspended then core will runtime resume you before
> >> >>>> invoking suspend, so why do we need this
> >> >>>
> >> >>> Is this change now in the mainline? Do you have commit ID for that?
> >> >>>
> >> >>> I recall the last time we discussed this that Rafael said that they were
> >> >>> going to do that, but he said as a rule of thumb if you need to resume
> >> >>> it, resume it [0].
> >> >> 
> >> >> IIRC this has been always the behaviour, at least I see this when I test the
> >> >> devices
> >> >
> >> > I have been doing some testing today and if the DMA is runtime
> >> > suspended, then I don't see it runtime resumed before suspend is called.
> >> >
> >> > Can you elborate on "at least I see this when I test the devices"? What
> >> > are you looking at? Are you using kernel function tracers in some way?
> >> 
> >> The PM core does a _get_noresume()[1] which tries to prevent runtime
> >> suspends *during* a system suspend.  However, the PM core should not be
> >> doing an actual runtime resume of the device, so if the device is
> >> already runtime suspended, it will not be runtime resumed by the core,
> >> so if the driver needs it to be runtime resumed, it needs to do it
> >> itself.
> >
> > + Rafael
> >
> > This is contrariry to what I see, If my driver is runtime suspended and on
> > suspend, it gets runtime resumed and then suspended
> 
> Since I was late to the thread, can you explain what kind of driver and
> on what bus type you're seeing this behavior?
> 
> It could be that your bus-type is doing something, but I don't think it
> should be the PM core.

Right.

Bus types do that, the core doesn't.  The ACPI PM domain does that too
for some devices.

So Vinod, more details, please.

Thanks,
Rafael


  reply	other threads:[~2015-11-05  1:46 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-16  8:25 [PATCH 0/6] dmaengine: tegra-apb: Various updates Jon Hunter
2015-10-16  8:25 ` [PATCH 1/6] dmaengine: tegra-apb: Correct runtime-pm usage Jon Hunter
2015-10-28  7:03   ` Vinod Koul
2015-10-28 13:32     ` Jon Hunter
2015-10-29  1:57       ` Vinod Koul
2015-11-03 16:23         ` Jon Hunter
2015-11-03 21:25           ` Kevin Hilman
2015-11-04  8:34             ` Vinod Koul
2015-11-04 16:59               ` Kevin Hilman
2015-11-05  2:15                 ` Rafael J. Wysocki [this message]
2015-11-05 12:17                   ` Vinod Koul
2015-10-16  8:25 ` [PATCH 2/6] dmaengine: tegra-apb: Use dev_get_drvdata() Jon Hunter
2015-10-16  8:25 ` [PATCH 3/6] dmaengine: tegra-apb: Save and restore word count Jon Hunter
2015-10-16  8:25 ` [PATCH 4/6] dmaengine: tegra-apb: Only save channel state for those in use Jon Hunter
2015-10-16  8:25 ` [PATCH 5/6] dmaengine: tegra-apb: Update driver to use GFP_NOWAIT Jon Hunter
2015-10-16  8:25 ` [PATCH 6/6] dmaengine: tegra-apb: Disable interrupts on removal Jon Hunter
2015-10-16  8:53   ` Lars-Peter Clausen
2015-10-16  9:29     ` Jon Hunter
2015-10-16 10:40       ` Lars-Peter Clausen
2015-10-16 10:57         ` Jon Hunter
2015-10-28  6:53           ` Vinod Koul
2015-10-28 13:34             ` 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=1564097.buIA8Wdn8f@vostro.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=dmaengine@vger.kernel.org \
    --cc=gnurou@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=khilman@kernel.org \
    --cc=ldewangan@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=swarren@wwwdotorg.org \
    --cc=thierry.reding@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome