From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Pavel Machek <pavel@ucw.cz>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Oliver Neukum <oneukum@suse.de>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Irina Tirdea <irina.tirdea@intel.com>,
Len Brown <len.brown@intel.com>,
Octavian Purdila <octavian.purdila@intel.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>
Subject: Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend
Date: Mon, 28 Sep 2015 15:47:22 +0200 [thread overview]
Message-ID: <1859392.HSqFSV3NKL@vostro.rjw.lan> (raw)
In-Reply-To: <20150927170217.GA3303@xo-6d-61-c0.localdomain>
On Sunday, September 27, 2015 07:02:17 PM Pavel Machek wrote:
> Hi!
Hi,
> > > > > That, or there may be an additional value, say "aggressive", to write to the
> > > > > control file in which case it becomes just
> > > > >
> > > > > echo aggressive >/sys/.../power/control
> > > >
> > > > That said I suppose that the "off" value for the "wakeup" file might also be
> > > > useful in some other cases, so it likely is a better approach.
> > >
> > > We still need some sort of "inhibit" callback for cases where the
> > > driver doesn't want to go into runtime suspend but does want to turn
> > > off all I/O. Should this callback be triggered when the user writes
> > > "off" to power/wakeup, or when the user writes "inhibit" to
> > > power/control, or should there be a separate sysfs attribute?
> >
> > My first thought is that if there is a separate attribute, then it only actually
> > makes sense for devices that generate input events, while the "off" thing may
> > be generally useful in principle (eg. it may indicate to disable PME for the
> > device to the PCI layer etc).
> >
> > OTOH, the additional "inhibit" attribute may only be exposed if the corresponding
> > callback is present, so I'm not really sure.
> >
> > Question is, though, what's the use case for turning off I/O when we don't
> > go into runtime suspend. After all, runtime suspend need not mean putting
>
> Well... In "cellphone goes to pocket" case, you want to turn off I/O even if
> the touchscreen can not support runtime suspend.
>
> See parents in the thread for explanation.
You seem to be confusing the ability to go into low-power states with supporting
runtime PM. The latter by no means requires the former.
Also "cellphone goes to pocket" is really two different cases. One is when
the user indicated "I'm not going to use the phone going forward" somehow (like
by pressing a screen-off button) and one is when (s)he didn't.
In the second case we really have no reason to discard any input and in the
first one we may as well go straight for runtime suspend (or even for system
suspend for that matter).
Thanks,
Rafael
next prev parent reply other threads:[~2015-09-28 13:19 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-07 20:42 Irina Tirdea
2015-09-07 21:20 ` Rafael J. Wysocki
2015-09-08 1:10 ` Tirdea, Irina
2015-09-08 7:35 ` Oliver Neukum
2015-09-08 20:56 ` Rafael J. Wysocki
2015-09-08 22:25 ` Ulf Hansson
2015-09-08 23:50 ` Rafael J. Wysocki
2015-09-09 11:13 ` Octavian Purdila
2015-09-09 12:22 ` Rafael J. Wysocki
2015-09-09 13:55 ` Oliver Neukum
2015-09-09 15:02 ` Octavian Purdila
2015-09-09 20:25 ` Rafael J. Wysocki
2015-09-10 9:38 ` Oliver Neukum
2015-09-21 12:29 ` Pavel Machek
2015-09-09 15:20 ` Alan Stern
2015-09-09 20:35 ` Rafael J. Wysocki
2015-09-09 20:16 ` Colin Cross
2015-09-21 12:30 ` Pavel Machek
2015-09-21 14:38 ` Alan Stern
2015-09-21 16:16 ` Dmitry Torokhov
2015-09-21 16:34 ` Alan Stern
2015-09-21 16:59 ` Dmitry Torokhov
2015-09-21 17:32 ` Alan Stern
2015-09-21 18:00 ` Dmitry Torokhov
2015-09-21 20:02 ` Alan Stern
2015-09-21 20:56 ` Dmitry Torokhov
2015-09-22 12:05 ` Oliver Neukum
2015-09-22 14:15 ` Alan Stern
2015-09-22 14:31 ` Oliver Neukum
2015-09-22 15:22 ` Alan Stern
2015-09-23 3:03 ` Oliver Neukum
2015-09-23 7:27 ` Octavian Purdila
2015-09-23 14:55 ` Alan Stern
2015-09-25 0:43 ` Rafael J. Wysocki
2015-09-25 14:29 ` Alan Stern
2015-09-25 20:15 ` Rafael J. Wysocki
2015-09-25 21:13 ` Alan Stern
2015-09-25 21:52 ` Rafael J. Wysocki
2015-09-25 23:04 ` Rafael J. Wysocki
2015-09-26 15:20 ` Alan Stern
2015-09-27 13:41 ` Rafael J. Wysocki
2015-09-27 14:27 ` Alan Stern
2015-09-28 13:41 ` Rafael J. Wysocki
2015-09-28 14:29 ` Alan Stern
2015-09-28 20:03 ` Rafael J. Wysocki
2015-09-28 20:23 ` Alan Stern
2015-10-04 15:16 ` Pavel Machek
2015-09-27 17:02 ` Pavel Machek
2015-09-28 13:47 ` Rafael J. Wysocki [this message]
2015-09-21 20:20 ` Pavel Machek
2015-09-08 14:44 ` Alan Stern
2015-09-08 15:15 ` Rafael J. Wysocki
2015-09-08 15:00 ` Alan Stern
2015-09-08 20:28 ` Rafael J. Wysocki
2015-09-09 15:22 ` Alan Stern
2015-09-09 6:26 ` Oliver Neukum
2015-09-09 14:33 ` Alan Stern
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=1859392.HSqFSV3NKL@vostro.rjw.lan \
--to=rjw@rjwysocki.net \
--cc=dmitry.torokhov@gmail.com \
--cc=irina.tirdea@intel.com \
--cc=len.brown@intel.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=octavian.purdila@intel.com \
--cc=oneukum@suse.de \
--cc=pavel@ucw.cz \
--cc=rafael@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
all inboxes | Powered by JetHome®