linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Linux PM list <linux-pm@vger.kernel.org>,
	Linux PCI <linux-pci@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Kevin Hilman <khilman@kernel.org>
Subject: Re: [PATCH 0/4] PM: Use CONFIG_PM instead of CONFIG_PM_RUNTIME in core code
Date: Thu, 27 Nov 2014 22:35:15 +0100	[thread overview]
Message-ID: <1803282.Wzz7IausxS@vostro.rjw.lan> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1411271216470.8104-100000@netrider.rowland.org>

On Thursday, November 27, 2014 12:18:23 PM Alan Stern wrote:
> On Thu, 27 Nov 2014, Geert Uytterhoeven wrote:
> 
> > Hi Rafael,
> > 
> > On Thu, Nov 27, 2014 at 5:52 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > >> I have also tested the two Kconfig options; CONFIG_PM_SLEEP (which
> > >> selects CONFIG_PM_RUNTIME) and for CONFIG_PM_RUNTIME (with
> > >> CONFIG_PM_SLEEP unset).
> > >>
> > >> That brings me to a raise a question; why do we need to keep these two
> > >> configurations options? Couldn't we also have CONFIG_PM_RUNTIME to
> > >> select CONFIG_PM_SLEEP, that will further simplify things?
> > >
> > > My plan is different.  I'm going to eliminate PM_RUNTIME from the code
> > > and then replace it with PM as a selectable option.  Then, PM_SLEEP will
> > > select PM (directly) and PM_RUNTIME can be entirely dropped.
> > 
> > What's your rationale for keeping PM_SLEEP, and not consolidating both
> > PM_RUNTIME and PM_SLEEP into PM? I.e. what am I missing, still
> > considering myself a PM newbie?
> > 
> > > So in the end we'll have one Kconfig option less, which is a win IMO.
> > 
> > Having two less may be a bigger win ;-)
> 
> I imagine that Rafael would like to continue supporting platforms that 
> want to have runtime power management but not suspend or hibernation.  
> A number of embedded systems might fall into this category.

Right.

That said whether or not it is ever useful to set PM_RUNTIME alone is a good
question.  In my opinion it is useful today, at least on some platforms that
don't really support system suspend or hibernation in any form.  However, it
may not be the case any more when suspend-to-idle becomes mature enough,
because that should just work for any platform without any kind of special
support.  We're still missing some timekeeping bits there, but once that
gap has been covered, we may just eliminate PM_SLEEP as well if there's a
broad consensus on that.

Rafael


  reply	other threads:[~2014-11-27 21:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-27  0:37 [PATCH 0/4] PM: Use CONFIG_PM instead of CONFIG_PM_RUNTIME in core code Rafael J. Wysocki
2014-11-27  0:38 ` [PATCH 1/4] PM: Drop the SET_PM_RUNTIME_PM_OPS() macro Rafael J. Wysocki
2014-11-27 22:05   ` [Replacement][PATCH 1/4] PM: Merge the SET*_RUNTIME_PM_OPS() macros Rafael J. Wysocki
2014-11-29  0:52     ` Rafael J. Wysocki
2014-12-03 14:15   ` [PATCH 1/4] PM: Drop the SET_PM_RUNTIME_PM_OPS() macro Ulf Hansson
2014-12-03 22:51     ` Rafael J. Wysocki
2014-12-04 10:04       ` Ulf Hansson
2014-12-04 21:48         ` Rafael J. Wysocki
2014-11-27  0:39 ` [PATCH 2/4] PM: Drop CONFIG_PM_RUNTIME from the driver core Rafael J. Wysocki
2014-11-27  0:40 ` [PATCH 3/4] ACPI / PM: Drop CONFIG_PM_RUNTIME from the ACPI core Rafael J. Wysocki
2014-11-27 22:06   ` [Update][PATCH " Rafael J. Wysocki
2014-11-27  0:40 ` [PATCH 4/4] PCI / PM: Drop CONFIG_PM_RUNTIME from the PCI core Rafael J. Wysocki
2014-11-27 22:41   ` [Update][PATCH " Rafael J. Wysocki
2014-12-01 22:51     ` Bjorn Helgaas
2014-11-27  8:57 ` [PATCH 0/4] PM: Use CONFIG_PM instead of CONFIG_PM_RUNTIME in core code Ulf Hansson
2014-11-27  9:20   ` Ulf Hansson
2014-11-27 16:52   ` Rafael J. Wysocki
2014-11-27 17:00     ` Geert Uytterhoeven
2014-11-27 17:18       ` Alan Stern
2014-11-27 21:35         ` Rafael J. Wysocki [this message]
2014-11-27 22:34           ` Ulf Hansson
2014-11-29  0:50             ` Rafael J. Wysocki
2014-12-02  1:01 ` Kevin Hilman

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=1803282.Wzz7IausxS@vostro.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=bhelgaas@google.com \
    --cc=geert@linux-m68k.org \
    --cc=khilman@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    --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 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).