All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@baylibre.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	linux-pm@vger.kernel.org, Len Brown <len.brown@intel.com>,
	Pavel Machek <pavel@ucw.cz>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Lina Iyer <lina.iyer@linaro.org>,
	Axel Haslam <ahaslam@baylibre.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Jon Hunter <jonathanh@nvidia.com>,
	Andy Gross <andy.gross@linaro.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH 3/4] PM / Domains: Allow runtime PM during system PM phases
Date: Mon, 23 May 2016 16:06:37 -0700	[thread overview]
Message-ID: <m2zirgidc2.fsf@baylibre.com> (raw)
In-Reply-To: <1463485296-22742-4-git-send-email-ulf.hansson@linaro.org> (Ulf Hansson's message of "Tue, 17 May 2016 13:41:35 +0200")

Ulf Hansson <ulf.hansson@linaro.org> writes:

> The PM core disables runtime PM at __device_suspend_late() before it calls
> a system PM "late" callback for the device. When resuming the device,
> after the corresponding "early" callback has been invoked, it re-enables
> runtime PM.
>
> By changing genpd to conform to this behaviour, the device no longer have
> to be unconditionally runtime resumed from genpd's ->prepare() callback. In
> most cases that avoids unnecessary operations.

...avoids the unnecessary, and energy-wasting operaions of runtime
resuming devices that have nothing to do, only to runtime suspend them
shortly after.

> As runtime PM then isn't disabled/enabled by genpd, the subsystem/driver
> can rely on the generic behaviour from PM core. Consequentially runtime PM
> is allowed in more phases of system PM than before.

OK.  I like this change a lot, but it the changelog doesn't go into
describing how this gets around the problems that were being worked
around by having genpd disable runtime PM in the first place.  This
changelog should describe how this appraoch deals with those problems,
or why they don't exist anymore.

> Although, because of this change and due to that genpd powers on the PM
> domain unconditionally in the system PM resume "noirq" phase, it could
> potentially cause a PM domain to stay powered on even if it's unused after
> the system has resumed. To avoid this, let's schedule a power off work
> when genpd's system PM ->complete() callback has been invoked for the last
> device in the PM domain.

OK.

> Another issue that arises due to this change in genpd, concerns those
> platforms/PM domains that makes use of genpd's device ->stop|start()
> callbacks. In these scenarios, the corresponding subsystem/driver needs to
> invoke pm_runtime_force_suspend() from a system PM suspend callback to
> allow genpd's ->runtime_suspend() to be invoked for an active device, else
> genpd can't "stop" a device that is "started".
>
> The subsystem/driver also needs to invoke pm_runtime_force_resume()
> in a system PM resume callback, to restore the runtime PM state for the
> device and to re-enable runtime PM.
>
> Currently not all involved subsystem/drivers makes use of
> pm_runtime_force_suspend|resume() accordingly. Therefore, let's invoke
> pm_runtime_force_suspend|resume() from genpd's "noirq" system PM
> callbacks, in cases when the ->stop|start() callbacks are being used.
>
> In this way, devices are "stoped" during suspend and "started" during
> resume, even in those cases when the subsystem/driver don't call
> pm_runtime_force_suspend|resume() themselves.

IMO, this last part might be better dealt with as a separate patch, so
it's clear which parts are for the main genpd change, and which parts
fixup the fallout.

On a related note, are there many genpd drivers using dev_ops->start and
->stop out there?  A quick grep didn't find anything other than the
pm_clk stuff.

Kevin

  reply	other threads:[~2016-05-23 23:06 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-17 11:41 [PATCH 0/4] PM / Domains / Runtime: Optimize device system PM when using genpd Ulf Hansson
2016-05-17 11:41 ` [PATCH 1/4] PM / Domains: Remove redundant call to pm_request_idle() in genpd Ulf Hansson
2016-05-23 21:25   ` Kevin Hilman
2016-05-24  6:19     ` Ulf Hansson
2016-05-17 11:41 ` [PATCH 2/4] PM / Runtime: Prevent re-resuming devices in pm_runtime_force_resume() Ulf Hansson
2016-05-23 21:30   ` Kevin Hilman
2016-05-24  6:30     ` Ulf Hansson
2016-05-24 18:31       ` Kevin Hilman
2016-05-17 11:41 ` [PATCH 3/4] PM / Domains: Allow runtime PM during system PM phases Ulf Hansson
2016-05-23 23:06   ` Kevin Hilman [this message]
2016-05-24  6:40     ` Ulf Hansson
2016-05-17 11:41 ` [PATCH 4/4] PM / Runtime: Defer resuming of the device in pm_runtime_force_resume() Ulf Hansson
2016-05-23 23:15   ` Kevin Hilman
2016-05-24  6:51     ` Ulf Hansson
2016-05-24 18:34       ` Kevin Hilman
2016-06-28 16:26   ` Geert Uytterhoeven
2016-06-29  0:26     ` Rafael J. Wysocki
2016-06-29 17:30     ` Ulf Hansson
2016-07-04 13:57       ` Geert Uytterhoeven
2016-06-30 22:40     ` Kevin Hilman
2016-07-04 13:53       ` Geert Uytterhoeven

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=m2zirgidc2.fsf@baylibre.com \
    --to=khilman@baylibre.com \
    --cc=ahaslam@baylibre.com \
    --cc=andy.gross@linaro.org \
    --cc=geert+renesas@glider.be \
    --cc=jonathanh@nvidia.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=len.brown@intel.com \
    --cc=lina.iyer@linaro.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    --cc=ulf.hansson@linaro.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.