From: Sudeep Holla <sudeep.holla@arm.com> To: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Maulik Shah <mkshah@codeaurora.org>, swboyd@chromium.org, agross@kernel.org, david.brown@linaro.org, Lorenzo.Pieralisi@arm.com, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, evgreen@chromium.org, dianders@chromium.org, rnayak@codeaurora.org, ilina@codeaurora.org, lsrao@codeaurora.org, ulf.hansson@linaro.org, rjw@rjwysocki.net Subject: Re: [PATCH v3 5/7] drivers: firmware: psci: Add hierarchical domain idle states converter Date: Fri, 7 Feb 2020 11:25:09 +0000 [thread overview] Message-ID: <20200207112508.GB40103@bogus> (raw) In-Reply-To: <20200206211133.GR2514@yoga> On Thu, Feb 06, 2020 at 01:11:33PM -0800, Bjorn Andersson wrote: > On Wed 05 Feb 06:06 PST 2020, Sudeep Holla wrote: > > > On Wed, Feb 05, 2020 at 05:53:00PM +0530, Maulik Shah wrote: > > > > > > On 2/4/2020 8:51 PM, Sudeep Holla wrote: > > > > On Tue, Feb 04, 2020 at 10:22:42AM +0530, Maulik Shah wrote: > > > > > On 2/3/2020 10:38 PM, Sudeep Holla wrote: > > > > > > On Mon, Feb 03, 2020 at 07:05:38PM +0530, Maulik Shah wrote: > > > > > > > From: Ulf Hansson <ulf.hansson@linaro.org> > > > > > > > > > > > > > > If the hierarchical CPU topology is used, but the OS initiated mode isn't > > > > > > > supported, we need to rely solely on the regular cpuidle framework to > > > > > > > manage the idle state selection, rather than using genpd and its > > > > > > > governor. > > > > > > > > > > > > > > For this reason, introduce a new PSCI DT helper function, > > > > > > > psci_dt_pm_domains_parse_states(), which parses and converts the > > > > > > > hierarchically described domain idle states from DT, into regular flattened > > > > > > > cpuidle states. The converted states are added to the existing cpuidle > > > > > > > driver's array of idle states, which make them available for cpuidle. > > > > > > > > > > > > > And what's the main motivation for this if OSI is not supported in the > > > > > > firmware ? > > > > > Hi Sudeep, > > > > > > > > > > Main motivation is to do last-man activities before the CPU cluster can > > > > > enter a deep idle state. > > > > > > > > > Details on those last-man activities will help the discussion. Basically > > > > I am wondering what they are and why they need to done in OSPM ? > > > > > > Hi Sudeep, > > > > > > there are cases like, > > > > > > Last cpu going to deepest idle mode need to lower various resoruce > > > requirements (for eg DDR freq). > > > > > > > In PC mode, only PSCI implementation knows the last man and there shouldn't > > be any notion of it in OS. If you need it, you may need OSI. You are still > > mixing up the things. NACK for any such approach, sorry. > > > > Forgive me if I'm misunderstanding PSCI's role here, but doesn't it deal > with the power management of the "processor subsystem" in the SoC? > Yes. > In the Qualcomm platforms most resources (voltage rails, clocks, etc) > are controlled through a power controller that provides controls for a > state when the CPU subsystem is running and when it's asleep. This > allows non-CPU-related device to control if resources that are shared > with the CPU subsystem should be kept on when the last CPU/cluster goes > down. > I understand that. > An example of this would be the display controller voting to keep a > voltage rail on after the CPU subsystem collapses, because the display > is still on. > OK > But as long as the CPU subsystem is running it will keep these resources > available and there's no need to change these votes (e.g. if the display > is turned on and off while the CPU is active the sleep-requests cancels > out), so they are simply cached/batched up in the RPMh driver and what > Maulik's series is attempting to do is to flush the cached values when > Linux believes that the firmware might decide to enter a lower power > state. > I understand all these. What I am arguing is that in PC mode, PSCI firmware is the one who needs to vote and not OSPM because it is responsible for pulling the plugs off the CPU/Cluster. So lets us not bring that to OSPM. OSI was invented to do all such crazy things in OSPM, please feel free to play with that ;-) -- Regards, Sudeep
WARNING: multiple messages have this Message-ID (diff)
From: Sudeep Holla <sudeep.holla@arm.com> To: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Maulik Shah <mkshah@codeaurora.org>, lsrao@codeaurora.org, Lorenzo.Pieralisi@arm.com, rnayak@codeaurora.org, linux-pm@vger.kernel.org, linux-arm-msm@vger.kernel.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, evgreen@chromium.org, swboyd@chromium.org, david.brown@linaro.org, agross@kernel.org, ilina@codeaurora.org, dianders@chromium.org, ulf.hansson@linaro.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3 5/7] drivers: firmware: psci: Add hierarchical domain idle states converter Date: Fri, 7 Feb 2020 11:25:09 +0000 [thread overview] Message-ID: <20200207112508.GB40103@bogus> (raw) In-Reply-To: <20200206211133.GR2514@yoga> On Thu, Feb 06, 2020 at 01:11:33PM -0800, Bjorn Andersson wrote: > On Wed 05 Feb 06:06 PST 2020, Sudeep Holla wrote: > > > On Wed, Feb 05, 2020 at 05:53:00PM +0530, Maulik Shah wrote: > > > > > > On 2/4/2020 8:51 PM, Sudeep Holla wrote: > > > > On Tue, Feb 04, 2020 at 10:22:42AM +0530, Maulik Shah wrote: > > > > > On 2/3/2020 10:38 PM, Sudeep Holla wrote: > > > > > > On Mon, Feb 03, 2020 at 07:05:38PM +0530, Maulik Shah wrote: > > > > > > > From: Ulf Hansson <ulf.hansson@linaro.org> > > > > > > > > > > > > > > If the hierarchical CPU topology is used, but the OS initiated mode isn't > > > > > > > supported, we need to rely solely on the regular cpuidle framework to > > > > > > > manage the idle state selection, rather than using genpd and its > > > > > > > governor. > > > > > > > > > > > > > > For this reason, introduce a new PSCI DT helper function, > > > > > > > psci_dt_pm_domains_parse_states(), which parses and converts the > > > > > > > hierarchically described domain idle states from DT, into regular flattened > > > > > > > cpuidle states. The converted states are added to the existing cpuidle > > > > > > > driver's array of idle states, which make them available for cpuidle. > > > > > > > > > > > > > And what's the main motivation for this if OSI is not supported in the > > > > > > firmware ? > > > > > Hi Sudeep, > > > > > > > > > > Main motivation is to do last-man activities before the CPU cluster can > > > > > enter a deep idle state. > > > > > > > > > Details on those last-man activities will help the discussion. Basically > > > > I am wondering what they are and why they need to done in OSPM ? > > > > > > Hi Sudeep, > > > > > > there are cases like, > > > > > > Last cpu going to deepest idle mode need to lower various resoruce > > > requirements (for eg DDR freq). > > > > > > > In PC mode, only PSCI implementation knows the last man and there shouldn't > > be any notion of it in OS. If you need it, you may need OSI. You are still > > mixing up the things. NACK for any such approach, sorry. > > > > Forgive me if I'm misunderstanding PSCI's role here, but doesn't it deal > with the power management of the "processor subsystem" in the SoC? > Yes. > In the Qualcomm platforms most resources (voltage rails, clocks, etc) > are controlled through a power controller that provides controls for a > state when the CPU subsystem is running and when it's asleep. This > allows non-CPU-related device to control if resources that are shared > with the CPU subsystem should be kept on when the last CPU/cluster goes > down. > I understand that. > An example of this would be the display controller voting to keep a > voltage rail on after the CPU subsystem collapses, because the display > is still on. > OK > But as long as the CPU subsystem is running it will keep these resources > available and there's no need to change these votes (e.g. if the display > is turned on and off while the CPU is active the sleep-requests cancels > out), so they are simply cached/batched up in the RPMh driver and what > Maulik's series is attempting to do is to flush the cached values when > Linux believes that the firmware might decide to enter a lower power > state. > I understand all these. What I am arguing is that in PC mode, PSCI firmware is the one who needs to vote and not OSPM because it is responsible for pulling the plugs off the CPU/Cluster. So lets us not bring that to OSPM. OSI was invented to do all such crazy things in OSPM, please feel free to play with that ;-) -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-02-07 11:25 UTC|newest] Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-03 13:35 [PATCH v3 0/7] Add RSC power domain support Maulik Shah 2020-02-03 13:35 ` Maulik Shah 2020-02-03 13:35 ` [PATCH v3 1/7] drivers: qcom: rpmh: fix macro to accept NULL argument Maulik Shah 2020-02-03 13:35 ` Maulik Shah 2020-02-03 13:35 ` [PATCH v3 2/7] drivers: qcom: rpmh: remove rpmh_flush export Maulik Shah 2020-02-03 13:35 ` Maulik Shah 2020-02-03 13:35 ` [PATCH v3 3/7] dt-bindings: soc: qcom: Add RSC power domain specifier Maulik Shah 2020-02-03 13:35 ` Maulik Shah 2020-02-03 13:35 ` [PATCH v3 4/7] drivers: qcom: rpmh-rsc: Add RSC power domain support Maulik Shah 2020-02-03 13:35 ` Maulik Shah 2020-02-03 13:35 ` [PATCH v3 5/7] drivers: firmware: psci: Add hierarchical domain idle states converter Maulik Shah 2020-02-03 13:35 ` Maulik Shah 2020-02-03 17:08 ` Sudeep Holla 2020-02-03 17:08 ` Sudeep Holla 2020-02-04 4:52 ` Maulik Shah 2020-02-04 4:52 ` Maulik Shah 2020-02-04 15:21 ` Sudeep Holla 2020-02-04 15:21 ` Sudeep Holla 2020-02-05 12:23 ` Maulik Shah 2020-02-05 12:23 ` Maulik Shah 2020-02-05 14:06 ` Sudeep Holla 2020-02-05 14:06 ` Sudeep Holla 2020-02-05 15:55 ` Ulf Hansson 2020-02-05 15:55 ` Ulf Hansson 2020-02-05 16:18 ` Sudeep Holla 2020-02-05 16:18 ` Sudeep Holla 2020-02-06 8:45 ` Ulf Hansson 2020-02-06 8:45 ` Ulf Hansson 2020-02-06 20:45 ` Lina Iyer 2020-02-06 20:45 ` Lina Iyer 2020-02-07 11:20 ` Sudeep Holla 2020-02-07 11:20 ` Sudeep Holla 2020-02-07 12:32 ` Ulf Hansson 2020-02-07 12:32 ` Ulf Hansson 2020-02-07 14:48 ` Lorenzo Pieralisi 2020-02-07 14:48 ` Lorenzo Pieralisi 2020-02-07 15:52 ` Ulf Hansson 2020-02-07 15:52 ` Ulf Hansson 2020-02-07 16:15 ` Sudeep Holla 2020-02-07 16:15 ` Sudeep Holla 2020-02-08 10:25 ` Ulf Hansson 2020-02-08 10:25 ` Ulf Hansson 2020-02-10 10:31 ` Sudeep Holla 2020-02-10 10:31 ` Sudeep Holla 2020-02-07 16:05 ` Sudeep Holla 2020-02-07 16:05 ` Sudeep Holla 2020-02-06 21:11 ` Bjorn Andersson 2020-02-06 21:11 ` Bjorn Andersson 2020-02-07 11:25 ` Sudeep Holla [this message] 2020-02-07 11:25 ` Sudeep Holla 2020-02-03 13:35 ` [PATCH v3 6/7] arm64: dts: qcom: sc7180: Add cpuidle low power states Maulik Shah 2020-02-03 13:35 ` Maulik Shah 2020-02-04 23:15 ` Matthias Kaehlcke 2020-02-04 23:15 ` Matthias Kaehlcke 2020-02-05 12:07 ` Maulik Shah 2020-02-05 12:07 ` Maulik Shah 2020-02-03 13:35 ` [PATCH v3 7/7] arm64: dts: qcom: sc7180: Convert to the hierarchical CPU topology layout Maulik Shah 2020-02-03 13:35 ` Maulik Shah
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=20200207112508.GB40103@bogus \ --to=sudeep.holla@arm.com \ --cc=Lorenzo.Pieralisi@arm.com \ --cc=agross@kernel.org \ --cc=bjorn.andersson@linaro.org \ --cc=david.brown@linaro.org \ --cc=dianders@chromium.org \ --cc=evgreen@chromium.org \ --cc=ilina@codeaurora.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=lsrao@codeaurora.org \ --cc=mkshah@codeaurora.org \ --cc=rjw@rjwysocki.net \ --cc=rnayak@codeaurora.org \ --cc=swboyd@chromium.org \ --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.