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: Re: Drivers taking different actions depending on sleep state
Date: Fri, 9 Jun 2017 18:27:45 +0200 [thread overview]
Message-ID: <0181d683-511e-1ff6-3855-e00849863e74@free.fr> (raw)
In-Reply-To: <9dc7b7f4-e47d-59f3-3b51-52e0aefd2487@free.fr>
On 09/06/2017 17:20, Mason wrote:
> 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?
FWIW, here's a transcript of a parallel discussion on #armlinux
Mason385 The kernel supports several "levels" of sleeps (S0, S1, S3, S4) ... is it possible for drivers to differentiate which level is being entered/exited ?
kos_tom Mason385: ask abelloni, he knows this topic very well
Mason385 abelloni: I'd be happy to tap that knowledge of yours
Mason385 I think khilman also knows a thing or three
abelloni it is not currently possible
Mason385 abelloni: one of the drivers is responsible for loading/unloading microcode to the DSP, and this is a very long operation (on the order of 1-2 seconds) and the author wants to be able to avoid this unload/reload for "freeze"
Mason385 the current "solution" has been to export the requested state in a global variable exported to all kernel modules (bleh)
Mason385 IIUC, there is no better way then?
abelloni no, that is what we do on at91
Mason385 abelloni: I'm confused because there's already an argument passed to drivers to indicate the sleep state, only it's the same arg for every state. Did someone determine it is unnecessary for drivers to have that information? But then why have the parameter in the first place?
abelloni I think up until recently, the stance was that it was unnecessary for the drivers to have that info
abelloni I would like to change that too but currently, you can't have it
khilman Mason385: abelloni is right (unfortunately)
Mason385 khilman: so you would also recommend exporting a global variable then?
khilman I cannot confirm or deny such a recommendation.
khilman (but there is no other way)
Mason385 Don't worry, this code has negative chance to ever hit upstream
khilman curious though: is the reason to avoid the unload/reload just for optimization of suspend/resume time? or is it because the DSP actually loses context?
Mason385 on suspend to RAM, the chip is powered down and loses all context
khilman so the compromise solution I've used in this case is to make the driver a bit smarter.
khilman iow, the driver always saves context, but then on resume, checks to see if restore is actually needed before doing the full restore (which is usually the time consuming part)
khilman often that can be done by checking some register that has a known power-on reset value (that's different from the driver programmed state)
abelloni khilman: I think it would still be worth exporting the target state to the drivers
Mason385 khilman: I *think* even the suspend side of the problem is time-consuming
javier__ Mason385: silly question, but does it necessarily lose state because the machine is suspended to RAM and the DSP needs to be reset on resume or is because the DSP loses power?
abelloni It may be difficult for drivers to know whether the IP has lost state
abelloni Also, we only have one platform loosing state and now, all the previous SoC are taking the hit
khilman abelloni: sure, but the goal is still that the drivers try to be smart. Having the global variable is an optimization.
Mason385 javier__: there's some authentication required when S2R is involved (from the firmware)
javier__ Mason385: ah, Ok. I just asked because if it was the latter, the regulator subsystem has infrastructure to keep the regulators on during S2R
Mason385 javier__: OK so there's two issues. We are required to re-authenticate microcode when resuming from S2R (because someone "may" have tampered with the contents) and on suspend, power is cut to the DSPs and they lose context
Mason385 javier__: were you suggesting to keep power to the DSPs during S2R (I don't think that is possible in the chip)
javier__ Mason385: I wasn't suggesting since I don't know your HW and use case
Mason385 I meant if it was possible, of course
javier__ Mason385: yes, I was just mentioning that the regulator subsys had a regulator-on-in-suspend property since we had a similar issue with a chip and solved that way
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 18:27:45 +0200 [thread overview]
Message-ID: <0181d683-511e-1ff6-3855-e00849863e74@free.fr> (raw)
In-Reply-To: <9dc7b7f4-e47d-59f3-3b51-52e0aefd2487@free.fr>
On 09/06/2017 17:20, Mason wrote:
> 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?
FWIW, here's a transcript of a parallel discussion on #armlinux
Mason385 The kernel supports several "levels" of sleeps (S0, S1, S3, S4) ... is it possible for drivers to differentiate which level is being entered/exited ?
kos_tom Mason385: ask abelloni, he knows this topic very well
Mason385 abelloni: I'd be happy to tap that knowledge of yours
Mason385 I think khilman also knows a thing or three
abelloni it is not currently possible
Mason385 abelloni: one of the drivers is responsible for loading/unloading microcode to the DSP, and this is a very long operation (on the order of 1-2 seconds) and the author wants to be able to avoid this unload/reload for "freeze"
Mason385 the current "solution" has been to export the requested state in a global variable exported to all kernel modules (bleh)
Mason385 IIUC, there is no better way then?
abelloni no, that is what we do on at91
Mason385 abelloni: I'm confused because there's already an argument passed to drivers to indicate the sleep state, only it's the same arg for every state. Did someone determine it is unnecessary for drivers to have that information? But then why have the parameter in the first place?
abelloni I think up until recently, the stance was that it was unnecessary for the drivers to have that info
abelloni I would like to change that too but currently, you can't have it
khilman Mason385: abelloni is right (unfortunately)
Mason385 khilman: so you would also recommend exporting a global variable then?
khilman I cannot confirm or deny such a recommendation.
khilman (but there is no other way)
Mason385 Don't worry, this code has negative chance to ever hit upstream
khilman curious though: is the reason to avoid the unload/reload just for optimization of suspend/resume time? or is it because the DSP actually loses context?
Mason385 on suspend to RAM, the chip is powered down and loses all context
khilman so the compromise solution I've used in this case is to make the driver a bit smarter.
khilman iow, the driver always saves context, but then on resume, checks to see if restore is actually needed before doing the full restore (which is usually the time consuming part)
khilman often that can be done by checking some register that has a known power-on reset value (that's different from the driver programmed state)
abelloni khilman: I think it would still be worth exporting the target state to the drivers
Mason385 khilman: I *think* even the suspend side of the problem is time-consuming
javier__ Mason385: silly question, but does it necessarily lose state because the machine is suspended to RAM and the DSP needs to be reset on resume or is because the DSP loses power?
abelloni It may be difficult for drivers to know whether the IP has lost state
abelloni Also, we only have one platform loosing state and now, all the previous SoC are taking the hit
khilman abelloni: sure, but the goal is still that the drivers try to be smart. Having the global variable is an optimization.
Mason385 javier__: there's some authentication required when S2R is involved (from the firmware)
javier__ Mason385: ah, Ok. I just asked because if it was the latter, the regulator subsystem has infrastructure to keep the regulators on during S2R
Mason385 javier__: OK so there's two issues. We are required to re-authenticate microcode when resuming from S2R (because someone "may" have tampered with the contents) and on suspend, power is cut to the DSPs and they lose context
Mason385 javier__: were you suggesting to keep power to the DSPs during S2R (I don't think that is possible in the chip)
javier__ Mason385: I wasn't suggesting since I don't know your HW and use case
Mason385 I meant if it was possible, of course
javier__ Mason385: yes, I was just mentioning that the regulator subsys had a regulator-on-in-suspend property since we had a similar issue with a chip and solved that way
next prev parent reply other threads:[~2017-06-09 16:28 UTC|newest]
Thread overview: 118+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-09 15:20 Drivers taking different actions depending on sleep state Mason
2017-06-09 15:20 ` Mason
2017-06-09 16:27 ` Mason [this message]
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=0181d683-511e-1ff6-3855-e00849863e74@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: link
Be 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.