From: Mason <slash.tmp@free.fr> To: "Rafael J. Wysocki" <rjw@rjwysocki.net>, Pavel Machek <pavel@ucw.cz>, Kevin Hilman <khilman@kernel.org>, Ulf Hansson <ulf.hansson@linaro.org>, Daniel Lezcano <daniel.lezcano@linaro.org> Cc: linux-pm <linux-pm@vger.kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Thibaud Cornic <thibaud_cornic@sigmadesigns.com>, JB <jb_lescher@sigmadesigns.com> Subject: Drivers taking different actions depending on sleep state Date: Fri, 9 Jun 2017 17:20:18 +0200 [thread overview] Message-ID: <9dc7b7f4-e47d-59f3-3b51-52e0aefd2487@free.fr> (raw) Hello, I read the "Sleep States" documentation: https://www.kernel.org/doc/Documentation/power/states.txt It mentions /sys/power/mem_sleep but I don't have that in 4.9 # ll /sys/power/ -rw-r--r-- 1 root root 4096 Jan 1 00:31 pm_async -rw-r--r-- 1 root root 4096 Jan 1 00:31 pm_freeze_timeout -rw-r--r-- 1 root root 4096 Jan 1 00:31 state -rw-r--r-- 1 root root 4096 Jan 1 00:31 wakeup_count # cat /sys/power/state freeze mem Currently my platform's "mem" is a true suspend-to-RAM trigger, where drivers are supposed to save their state (register values will be lost), then Linux hands control over to firmware which enables RAM self-refresh and powers the chip down. When the system resumes, drivers restore their state from their copy in memory. One driver is responsible for loading/unloading microcode running on the DSPs. This operation is required only when powering down the chip, but it should be avoided for "low-latency" sleeps. The problem is that, if I understand correctly, drivers have no way of knowing which sleep state is being entered/exited? How can I have the microcode driver take different decisions based on the sleep state? Regards.
WARNING: multiple messages have this Message-ID (diff)
From: slash.tmp@free.fr (Mason) To: linux-arm-kernel@lists.infradead.org Subject: Drivers taking different actions depending on sleep state Date: Fri, 9 Jun 2017 17:20:18 +0200 [thread overview] Message-ID: <9dc7b7f4-e47d-59f3-3b51-52e0aefd2487@free.fr> (raw) Hello, I read the "Sleep States" documentation: https://www.kernel.org/doc/Documentation/power/states.txt It mentions /sys/power/mem_sleep but I don't have that in 4.9 # ll /sys/power/ -rw-r--r-- 1 root root 4096 Jan 1 00:31 pm_async -rw-r--r-- 1 root root 4096 Jan 1 00:31 pm_freeze_timeout -rw-r--r-- 1 root root 4096 Jan 1 00:31 state -rw-r--r-- 1 root root 4096 Jan 1 00:31 wakeup_count # cat /sys/power/state freeze mem Currently my platform's "mem" is a true suspend-to-RAM trigger, where drivers are supposed to save their state (register values will be lost), then Linux hands control over to firmware which enables RAM self-refresh and powers the chip down. When the system resumes, drivers restore their state from their copy in memory. One driver is responsible for loading/unloading microcode running on the DSPs. This operation is required only when powering down the chip, but it should be avoided for "low-latency" sleeps. The problem is that, if I understand correctly, drivers have no way of knowing which sleep state is being entered/exited? How can I have the microcode driver take different decisions based on the sleep state? Regards.
next reply other threads:[~2017-06-09 15:20 UTC|newest] Thread overview: 118+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-06-09 15:20 Mason [this message] 2017-06-09 15:20 ` Drivers taking different actions depending on sleep state Mason 2017-06-09 16:27 ` Mason 2017-06-09 16:27 ` Mason 2017-06-09 21:30 ` Pavel Machek 2017-06-09 21:30 ` Pavel Machek 2017-06-10 9:16 ` Mason 2017-06-10 9:16 ` Mason 2017-06-09 22:05 ` Florian Fainelli 2017-06-09 22:05 ` Florian Fainelli 2017-06-09 22:53 ` Rafael J. Wysocki 2017-06-09 22:53 ` Rafael J. Wysocki 2017-06-21 21:16 ` Florian Fainelli 2017-06-21 21:16 ` Florian Fainelli 2017-06-21 21:59 ` Rafael J. Wysocki 2017-06-21 21:59 ` Rafael J. Wysocki 2017-06-21 22:48 ` Florian Fainelli 2017-06-21 22:48 ` Florian Fainelli 2017-06-21 22:57 ` Rafael J. Wysocki 2017-06-21 22:57 ` Rafael J. Wysocki 2017-06-21 23:55 ` Florian Fainelli 2017-06-21 23:55 ` Florian Fainelli 2017-06-22 0:03 ` Rafael J. Wysocki 2017-06-22 0:03 ` Rafael J. Wysocki 2017-06-22 15:18 ` Florian Fainelli 2017-06-22 15:18 ` Florian Fainelli 2017-06-22 16:09 ` Rafael J. Wysocki 2017-06-22 16:09 ` Rafael J. Wysocki 2017-06-22 8:51 ` Alexandre Belloni 2017-06-22 8:51 ` Alexandre Belloni 2017-06-22 16:00 ` Rafael J. Wysocki 2017-06-22 16:00 ` Rafael J. Wysocki 2017-06-23 1:08 ` [RFC 0/2] PM / suspend: Add platform_suspend_target_state() Florian Fainelli 2017-06-23 1:08 ` Florian Fainelli 2017-06-23 1:08 ` [RFC 1/2] " Florian Fainelli 2017-06-23 1:08 ` Florian Fainelli 2017-06-29 23:00 ` Rafael J. Wysocki 2017-06-29 23:00 ` Rafael J. Wysocki 2017-07-12 18:08 ` Florian Fainelli 2017-07-12 18:08 ` Florian Fainelli 2017-07-14 22:16 ` Rafael J. Wysocki 2017-07-14 22:16 ` Rafael J. Wysocki 2017-07-15 6:28 ` Pavel Machek 2017-07-15 6:28 ` Pavel Machek 2017-07-15 12:17 ` Rafael J. Wysocki 2017-07-15 12:17 ` Rafael J. Wysocki 2017-07-15 16:46 ` Pavel Machek 2017-07-15 16:46 ` Pavel Machek 2017-07-15 17:20 ` Florian Fainelli 2017-07-15 17:20 ` Florian Fainelli 2017-07-15 18:33 ` Alexandre Belloni 2017-07-15 18:33 ` Alexandre Belloni 2017-07-06 3:18 ` Pavel Machek 2017-07-06 3:18 ` Pavel Machek 2017-07-16 13:41 ` Alexandre Belloni 2017-07-16 13:41 ` Alexandre Belloni 2017-07-16 15:35 ` Florian Fainelli 2017-07-16 15:35 ` Florian Fainelli 2017-07-15 23:24 ` Rafael J. Wysocki 2017-07-15 23:24 ` Rafael J. Wysocki 2017-07-15 23:34 ` Mason 2017-07-15 23:34 ` Mason 2017-07-15 23:38 ` Rafael J. Wysocki 2017-07-15 23:38 ` Rafael J. Wysocki 2017-07-16 2:36 ` Florian Fainelli 2017-07-16 2:36 ` Florian Fainelli 2017-07-16 10:22 ` Rafael J. Wysocki 2017-07-16 10:22 ` Rafael J. Wysocki 2017-07-16 13:38 ` Alexandre Belloni 2017-07-16 13:38 ` Alexandre Belloni 2017-07-16 18:24 ` Pavel Machek 2017-07-16 18:24 ` Pavel Machek 2017-07-16 15:41 ` Florian Fainelli 2017-07-16 15:41 ` Florian Fainelli 2017-07-15 23:29 ` Rafael J. Wysocki 2017-07-15 23:29 ` Rafael J. Wysocki 2017-07-06 3:17 ` Pavel Machek 2017-07-06 3:17 ` Pavel Machek 2017-07-16 10:28 ` Rafael J. Wysocki 2017-07-16 10:28 ` Rafael J. Wysocki 2017-07-16 18:22 ` Pavel Machek 2017-07-16 18:22 ` Pavel Machek 2017-06-23 1:08 ` [RFC 2/2] soc: bcm: brcmstb: PM: Implement target_state callback Florian Fainelli 2017-06-23 1:08 ` Florian Fainelli 2017-06-29 23:04 ` Rafael J. Wysocki 2017-06-29 23:04 ` Rafael J. Wysocki 2017-07-16 2:36 ` [PATCH 0/2] PM / suspend: Add platform_suspend_target_state() Florian Fainelli 2017-07-16 2:36 ` Florian Fainelli 2017-07-16 2:36 ` [PATCH 1/2] " Florian Fainelli 2017-07-16 2:36 ` Florian Fainelli 2017-07-06 3:18 ` Pavel Machek 2017-07-06 3:18 ` Pavel Machek 2017-07-16 15:41 ` Florian Fainelli 2017-07-16 15:41 ` Florian Fainelli 2017-07-16 10:30 ` Rafael J. Wysocki 2017-07-16 10:30 ` Rafael J. Wysocki 2017-07-16 2:36 ` [PATCH 2/2] soc: bcm: brcmstb: PM: Implement target_state callback Florian Fainelli 2017-07-16 2:36 ` Florian Fainelli 2017-07-17 20:06 ` [PATCH v2] PM / suspend: Add suspend_target_state() Florian Fainelli 2017-07-17 20:06 ` Florian Fainelli 2017-07-17 20:16 ` Pavel Machek 2017-07-17 20:16 ` Pavel Machek 2017-07-17 21:03 ` Rafael J. Wysocki 2017-07-17 21:03 ` Rafael J. Wysocki 2017-07-17 21:21 ` Florian Fainelli 2017-07-17 21:21 ` Florian Fainelli 2017-07-20 8:03 ` Pavel Machek 2017-07-20 8:03 ` Pavel Machek 2017-07-17 22:10 ` [PATCH v3] PM / suspend: Export pm_suspend_target_state Florian Fainelli 2017-07-17 22:10 ` Florian Fainelli 2017-07-17 23:24 ` Rafael J. Wysocki 2017-07-17 23:24 ` Rafael J. Wysocki 2017-07-18 0:19 ` [PATCH v4] " Florian Fainelli 2017-07-18 0:19 ` Florian Fainelli 2017-07-24 20:55 ` Rafael J. Wysocki 2017-07-24 20:55 ` Rafael J. Wysocki 2017-07-13 12:03 ` Drivers taking different actions depending on sleep state Pavel Machek 2017-07-13 12:03 ` Pavel Machek
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=9dc7b7f4-e47d-59f3-3b51-52e0aefd2487@free.fr \ --to=slash.tmp@free.fr \ --cc=daniel.lezcano@linaro.org \ --cc=jb_lescher@sigmadesigns.com \ --cc=khilman@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-pm@vger.kernel.org \ --cc=pavel@ucw.cz \ --cc=rjw@rjwysocki.net \ --cc=thibaud_cornic@sigmadesigns.com \ --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: linkBe 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.