From: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
To: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@gmail.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: How to power gate a specific single device from outside?
Date: Wed, 25 Oct 2017 20:42:39 +0100 [thread overview]
Message-ID: <20171025204239.47a80251@alans-desktop> (raw)
In-Reply-To: <CAHKzcEORSo2X7uEsOzeR7WpzN+2T4pYAdh1QDZ5nd9kBD-w=sA@mail.gmail.com>
> Now, what I need in the kernel is to _selectively_ suspend devices
> that are not needed in the "backup/emergency" mode.
Which means you need to get the applications using them to die - or you
could rewrite the driver top to bottom to have locking sufficient to
ensure that your power management changes don't interact with any
existing functionality and every function neatly aborts or errors in a
safe way to the userspace which you've also modified extensively to cope.
I knmow which I'd choose.
> If current state of the power frameworks for system sleep, runtime pm,
> genpd etc. are not able to handle this transition, and as far as I
> understand these subsystems they cannot handle this straight away
Correct - nor can you handle it straight away because you might be in the
middle of doing something so need to finish a transactio before you can
drop to a lower power level.
> In DT we could specify which devices should go in low power state when
> in emergency mode eg.
> node {
> ....
> suspend-in-emergency;
> .....
> }
If a component of your hardware has a low power mode then why aren't you
always putting it in lowest power mode except when it's in current use ?
> So the device driver knows if it should be suspended in
> PM_SUSPEND_EMERGENCY or not. The driver has to provide a callback in
> pm_ops to handle this transition or we could reuse suspend callback if
> possible.
You need to re-use the existing power management logic, and in many cases
that means you'll need to shut down the userspace processes that are
keeping the device busy because they will be keeping it from going to
sleep.
> Just a brief idea. Does it make sense to anyone?
So the normal way you do this kind of stuff is to use runlevels with init
(or the systemd equivalents)
When the power goes poof you change runlevel. init kills off and
shuts down all the services you want to drop. Those close the devices,
which being well behaved shove themselves into the deepest sleep they can.
When the power comes back you switch runlevel back and stuff respawns.
Alan
prev parent reply other threads:[~2017-10-25 19:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-24 8:34 How to power gate a specific single device from outside? Waldemar Rymarkiewicz
2017-10-24 23:56 ` Alan Cox
2017-10-25 12:15 ` Waldemar Rymarkiewicz
2017-10-25 19:42 ` Alan Cox [this message]
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=20171025204239.47a80251@alans-desktop \
--to=gnomes@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=waldemar.rymarkiewicz@gmail.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;
as well as URLs for NNTP newsgroup(s).