From: Alexandre Belloni <alexandre.belloni@free-electrons.com> To: Pavel Machek <pavel@ucw.cz> Cc: Florian Fainelli <f.fainelli@gmail.com>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, linux-kernel@vger.kernel.org, "Rafael J. Wysocki" <rafael@kernel.org>, Ulf Hansson <ulf.hansson@linaro.org>, Daniel Lezcano <daniel.lezcano@linaro.org>, linux-pm <linux-pm@vger.kernel.org>, Thibaud Cornic <thibaud_cornic@sigmadesigns.com>, JB <jb_lescher@sigmadesigns.com>, Mason <slash.tmp@free.fr>, Kevin Hilman <khilman@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org> Subject: Re: [RFC 1/2] PM / suspend: Add platform_suspend_target_state() Date: Sun, 16 Jul 2017 15:41:16 +0200 [thread overview] Message-ID: <20170716134116.wxwb3gevbhlereij@piout.net> (raw) In-Reply-To: <20170706031819.GD12954@xo-6d-61-c0.localdomain> On 06/07/2017 at 05:18:19 +0200, Pavel Machek wrote: > On Sat 2017-07-15 20:33:58, Alexandre Belloni wrote: > > On 15/07/2017 at 10:20:27 -0700, Florian Fainelli wrote: > > > > We already have > > > > > > > > struct regulator_state { > > > > int uV; /* suspend voltage */ > > > > unsigned int mode; /* suspend regulator operating mode */ > > > > int enabled; /* is regulator enabled in this suspend state */ > > > > int disabled; /* is the regulator disabled in this suspend state */ > > > > }; > > > > > > > > * struct regulation_constraints - regulator operating constraints. > > > > * @state_disk: State for regulator when system is suspended in disk > > > > * mode. > > > > * @state_mem: State for regulator when system is suspended in mem > > > > * mode. > > > > * @state_standby: State for regulator when system is suspended in > > > > * standby > > > > * mode. > > > > > > > > . So it seems that maybe we should tell the drivers if we are entering > > > > "state_mem" or "state_standby" (something I may have opposed, sorry), > > > > then the driver can get neccessary information from regulator > > > > framework. > > > > > > OK, so what would be the mechanism to tell these drivers about the > > > system wide suspend state they are entering if it is not via > > > platform_suspend_target_state()? > > > > > > Keep in mind that regulators might be one aspect of what could be > > > causing the platform to behave specifically in one suspend state vs. > > > another, but there could be pieces of HW within the SoC that can't be > > > described with power domains, voltage islands etc. that would still have > > > inherent suspend states properties (like memory retention, pin/pad > > > controls etc. etc). We still need some mechanism, possibly centralized > > > > > > > I concur, the regulator stuff is one aspect of one of our suspend state > > (cutting VDDcore). But we have another state where the main clock (going > > to the IPs) is going from a few hundred MHz to 32kHz. This is currently > > handled by calling at91_suspend_entering_slow_clock(). I think it is > > important to take that into account so we can remove this hack from the > > kernel. > > Cure should not be worse then the disease... and it is in this case. > > For clocks, take a look at clock framework, perhaps it already has "clock_will_be_suspended" > as regulator framework had. If not, implement it. > See Rafael's comment, currently, the clock framework can't say whether the clock will change because it doesn't know anything about the suspend target. > Same with memory retention, pin/pad controls. > Same here. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: alexandre.belloni@free-electrons.com (Alexandre Belloni) To: linux-arm-kernel@lists.infradead.org Subject: [RFC 1/2] PM / suspend: Add platform_suspend_target_state() Date: Sun, 16 Jul 2017 15:41:16 +0200 [thread overview] Message-ID: <20170716134116.wxwb3gevbhlereij@piout.net> (raw) In-Reply-To: <20170706031819.GD12954@xo-6d-61-c0.localdomain> On 06/07/2017 at 05:18:19 +0200, Pavel Machek wrote: > On Sat 2017-07-15 20:33:58, Alexandre Belloni wrote: > > On 15/07/2017 at 10:20:27 -0700, Florian Fainelli wrote: > > > > We already have > > > > > > > > struct regulator_state { > > > > int uV; /* suspend voltage */ > > > > unsigned int mode; /* suspend regulator operating mode */ > > > > int enabled; /* is regulator enabled in this suspend state */ > > > > int disabled; /* is the regulator disabled in this suspend state */ > > > > }; > > > > > > > > * struct regulation_constraints - regulator operating constraints. > > > > * @state_disk: State for regulator when system is suspended in disk > > > > * mode. > > > > * @state_mem: State for regulator when system is suspended in mem > > > > * mode. > > > > * @state_standby: State for regulator when system is suspended in > > > > * standby > > > > * mode. > > > > > > > > . So it seems that maybe we should tell the drivers if we are entering > > > > "state_mem" or "state_standby" (something I may have opposed, sorry), > > > > then the driver can get neccessary information from regulator > > > > framework. > > > > > > OK, so what would be the mechanism to tell these drivers about the > > > system wide suspend state they are entering if it is not via > > > platform_suspend_target_state()? > > > > > > Keep in mind that regulators might be one aspect of what could be > > > causing the platform to behave specifically in one suspend state vs. > > > another, but there could be pieces of HW within the SoC that can't be > > > described with power domains, voltage islands etc. that would still have > > > inherent suspend states properties (like memory retention, pin/pad > > > controls etc. etc). We still need some mechanism, possibly centralized > > > > > > > I concur, the regulator stuff is one aspect of one of our suspend state > > (cutting VDDcore). But we have another state where the main clock (going > > to the IPs) is going from a few hundred MHz to 32kHz. This is currently > > handled by calling at91_suspend_entering_slow_clock(). I think it is > > important to take that into account so we can remove this hack from the > > kernel. > > Cure should not be worse then the disease... and it is in this case. > > For clocks, take a look at clock framework, perhaps it already has "clock_will_be_suspended" > as regulator framework had. If not, implement it. > See Rafael's comment, currently, the clock framework can't say whether the clock will change because it doesn't know anything about the suspend target. > Same with memory retention, pin/pad controls. > Same here. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
next prev parent reply other threads:[~2017-07-16 13:41 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 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 [this message] 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=20170716134116.wxwb3gevbhlereij@piout.net \ --to=alexandre.belloni@free-electrons.com \ --cc=daniel.lezcano@linaro.org \ --cc=f.fainelli@gmail.com \ --cc=jb_lescher@sigmadesigns.com \ --cc=khilman@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=pavel@ucw.cz \ --cc=rafael@kernel.org \ --cc=rjw@rjwysocki.net \ --cc=slash.tmp@free.fr \ --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.