linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: "Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Thierry Reding <thierry.reding@gmail.com>
Cc: Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Dmitry Osipenko <digetx@gmail.com>,
	linux-pm@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-tegra@vger.kernel.org
Subject: [PATCH 0/2] PM / runtime: Allow drivers to override runtime PM behaviour on sleep
Date: Thu, 28 Nov 2019 17:03:12 +0100	[thread overview]
Message-ID: <20191128160314.2381249-1-thierry.reding@gmail.com> (raw)

From: Thierry Reding <treding@nvidia.com>

This is a result of looking into a more formal way of doing what was
proposed here:

	http://patchwork.ozlabs.org/patch/1145363/

The Tegra DRM driver is written such that runtime PM controls all
aspects of bringing up and shutting down the hardware associated with a
display pipeline. This works very nicely with the DRM/KMS atomic mode-
setting framework that has very rigorous call sequences. There are also
suspend/resume helpers for system sleep that are built on top of these
generic helpers and that cause the same code sequences to be run as if
users had simply chosen to disable all display pipelines at normal
runtime.

The current behaviour of the PM core to disallow runtime suspend/resume
during system sleep gets in the way of this because the devices do not
in fact runtime suspend/resume during that time. Most of the time this
causes display outputs to malfunction upon resume.

Now, there are good reasons for preventing runtime suspend during system
sleep, as given in commit eea3fc0357eb ("PCI / PM: Detect early wakeup
in pci_pm_prepare()") that originally introduced this mechanism. There
can, however, also be cases, like the one described above, where it is
safe to allow this. Add a flag and a set of helpers to set or clear that
new flag so that drivers that know it will be safe to runtime suspend a
device at system sleep time can mark the device as such.

If a device has the flag set, the PM core will no longer take a runtime
PM reference for it, thus allowing the device to runtime suspend at the
expected time.

Thierry

Thierry Reding (2):
  PM / runtime: Allow drivers to override runtime PM behaviour on sleep
  drm/tegra: Allow runtime suspend on system sleep

 drivers/base/power/main.c    |  6 ++++--
 drivers/base/power/runtime.c | 16 ++++++++++++++++
 drivers/gpu/drm/tegra/dc.c   |  1 +
 drivers/gpu/drm/tegra/dsi.c  |  1 +
 drivers/gpu/drm/tegra/hdmi.c |  1 +
 drivers/gpu/drm/tegra/hub.c  |  1 +
 drivers/gpu/drm/tegra/sor.c  |  1 +
 include/linux/pm.h           |  1 +
 include/linux/pm_runtime.h   |  2 ++
 9 files changed, 28 insertions(+), 2 deletions(-)

-- 
2.23.0


             reply	other threads:[~2019-11-28 16:03 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-28 16:03 Thierry Reding [this message]
2019-11-28 16:03 ` [PATCH 1/2] PM / runtime: Allow drivers to override runtime PM behaviour on sleep Thierry Reding
2019-11-28 16:14   ` Rafael J. Wysocki
2019-11-28 16:50     ` Thierry Reding
2019-11-28 22:03       ` Rafael J. Wysocki
2019-11-28 22:20         ` Rafael J. Wysocki
2019-11-29 10:08           ` Thierry Reding
2019-11-29 10:22             ` Rafael J. Wysocki
2019-11-29 12:07               ` Thierry Reding
2019-11-29 20:27                 ` Daniel Vetter
2019-12-04  0:02                 ` Rafael J. Wysocki
2019-11-29  9:33         ` Thierry Reding
2019-11-29 10:09           ` Rafael J. Wysocki
2019-11-29 11:44             ` Thierry Reding
2019-11-28 16:03 ` [PATCH 2/2] drm/tegra: Allow runtime suspend on system sleep Thierry Reding
2019-11-28 16:47 ` [PATCH 0/2] PM / runtime: Allow drivers to override runtime PM behaviour on sleep Daniel Vetter
2019-11-28 17:04   ` Thierry Reding

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=20191128160314.2381249-1-thierry.reding@gmail.com \
    --to=thierry.reding@gmail.com \
    --cc=digetx@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=len.brown@intel.com \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    /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).