From: Ulf Hansson <ulf.hansson@linaro.org> To: Sudeep Holla <sudeep.holla@arm.com> Cc: "Rafael J . Wysocki" <rjw@rjwysocki.net>, Daniel Lezcano <daniel.lezcano@linaro.org>, Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>, Mark Rutland <mark.rutland@arm.com>, Lina Iyer <ilina@codeaurora.org>, Linux PM <linux-pm@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>, Vincent Guittot <vincent.guittot@linaro.org>, Stephen Boyd <sboyd@kernel.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Kevin Hilman <khilman@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, linux-arm-msm <linux-arm-msm@vger.kernel.org> Subject: Re: [PATCH 10/13] cpuidle: psci: Add a helper to attach a CPU to its PM domain Date: Mon, 28 Oct 2019 08:35:55 +0100 [thread overview] Message-ID: <CAPDyKFr1LJ_HP1kcfMh7LE5j7nUT9KzH4vhdCSEE9wg6RfYErQ@mail.gmail.com> (raw) In-Reply-To: <20191027023023.GC18111@e107533-lin.cambridge.arm.com> On Sun, 27 Oct 2019 at 03:30, Sudeep Holla <sudeep.holla@arm.com> wrote: > > On Thu, Oct 24, 2019 at 06:47:43PM +0200, Ulf Hansson wrote: > > On Thu, 24 Oct 2019 at 18:31, Sudeep Holla <sudeep.holla@arm.com> wrote: > > > > > > On Thu, Oct 10, 2019 at 01:39:34PM +0200, Ulf Hansson wrote: > > > > Introduce a PSCI DT helper function, psci_dt_attach_cpu(), which takes a > > > > CPU number as an in-parameter and tries to attach the CPU's struct device > > > > to its corresponding PM domain. > > > > > > > > Let's makes use of dev_pm_domain_attach_by_name(), as it allows us to > > > > specify "psci" as the "name" of the PM domain to attach to. Additionally, > > > > let's also prepare the attached device to be power managed via runtime PM. > > > > > > > > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> > > > > --- > > > > drivers/cpuidle/cpuidle-psci-domain.c | 21 +++++++++++++++++++++ > > > > drivers/cpuidle/cpuidle-psci.h | 6 ++++++ > > > > 2 files changed, 27 insertions(+) > > > > > > > > diff --git a/drivers/cpuidle/cpuidle-psci-domain.c b/drivers/cpuidle/cpuidle-psci-domain.c > > > > index 3f5143ccc3e0..7429fd7626a1 100644 > > > > --- a/drivers/cpuidle/cpuidle-psci-domain.c > > > > +++ b/drivers/cpuidle/cpuidle-psci-domain.c > > > > @@ -9,9 +9,11 @@ > > > > > > > > #define pr_fmt(fmt) "CPUidle PSCI: " fmt > > > > > > > > +#include <linux/cpu.h> > > > > #include <linux/device.h> > > > > #include <linux/kernel.h> > > > > #include <linux/pm_domain.h> > > > > +#include <linux/pm_runtime.h> > > > > #include <linux/psci.h> > > > > #include <linux/slab.h> > > > > #include <linux/string.h> > > > > @@ -279,3 +281,22 @@ static int __init psci_idle_init_domains(void) > > > > return ret; > > > > } > > > > subsys_initcall(psci_idle_init_domains); > > > > + > > > > +struct device *psci_dt_attach_cpu(int cpu) > > > > +{ > > > > + struct device *dev; > > > > + > > > > + /* Currently limit the hierarchical topology to be used in OSI mode. */ > > > > + if (!psci_has_osi_support()) > > > > + return NULL; > > > > + > > > > + dev = dev_pm_domain_attach_by_name(get_cpu_device(cpu), "psci"); > > > > > > This clarifies the need for the fixed name. But why not just go by index 0 > > > as the consumer of these psci power-domains will have only one power domain > > > entry. Why do we need this name compulsory ? > > > > The idea is to be future proof. If I recall correctly, the CPU node on > > some QCOM SoCs may also have "CPR" PM domain specified, thus > > "multiple" power-domains could be specified. > > > > I am sure we don't want to mx-n-match any power domain provider with > psci. And also I expect in these above mentioned cases, there won't be any > psci power domains. > > > In any case, using "psci" doesn't really hurt, right? > > > > Doesn't but I don't see need for one as only one should exist, as mentioned > above we don't want mix-n-match with psci ever. Not sure I get your point, sorry. The CPU could very well be attached to more than one power-domain. Of course not multiple "PSCI power-domains". One could be an PSCI power domain and another one could be the QCOM CPR (Core power reduction) power domain. Have a look at these binding, there are already upstream, perhaps that clarifies this? Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt > > > > Further, it's specified as > > > optional in the generic binding, do we make it "required" for this psci > > > idle states binding anywhere that I missed ? > > > > Good point! Unless you tell me differently, I will update the DT doc > > to clarify this is "required". > > > > No but why is my question ? We don't have to. If firmware/DT wants to > specify the name, sure. But it must remain optional IMO. According the QCOM CPR case, we need a way to distinguish what power domain we should attach the CPU to. If we don't use power-domain-names to do that, what else should we use? Kind regards Uffe
WARNING: multiple messages have this Message-ID (diff)
From: Ulf Hansson <ulf.hansson@linaro.org> To: Sudeep Holla <sudeep.holla@arm.com> Cc: Mark Rutland <mark.rutland@arm.com>, Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>, Linux PM <linux-pm@vger.kernel.org>, Stephen Boyd <sboyd@kernel.org>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, Daniel Lezcano <daniel.lezcano@linaro.org>, "Rafael J . Wysocki" <rjw@rjwysocki.net>, Lina Iyer <ilina@codeaurora.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Kevin Hilman <khilman@kernel.org>, Rob Herring <robh+dt@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH 10/13] cpuidle: psci: Add a helper to attach a CPU to its PM domain Date: Mon, 28 Oct 2019 08:35:55 +0100 [thread overview] Message-ID: <CAPDyKFr1LJ_HP1kcfMh7LE5j7nUT9KzH4vhdCSEE9wg6RfYErQ@mail.gmail.com> (raw) In-Reply-To: <20191027023023.GC18111@e107533-lin.cambridge.arm.com> On Sun, 27 Oct 2019 at 03:30, Sudeep Holla <sudeep.holla@arm.com> wrote: > > On Thu, Oct 24, 2019 at 06:47:43PM +0200, Ulf Hansson wrote: > > On Thu, 24 Oct 2019 at 18:31, Sudeep Holla <sudeep.holla@arm.com> wrote: > > > > > > On Thu, Oct 10, 2019 at 01:39:34PM +0200, Ulf Hansson wrote: > > > > Introduce a PSCI DT helper function, psci_dt_attach_cpu(), which takes a > > > > CPU number as an in-parameter and tries to attach the CPU's struct device > > > > to its corresponding PM domain. > > > > > > > > Let's makes use of dev_pm_domain_attach_by_name(), as it allows us to > > > > specify "psci" as the "name" of the PM domain to attach to. Additionally, > > > > let's also prepare the attached device to be power managed via runtime PM. > > > > > > > > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> > > > > --- > > > > drivers/cpuidle/cpuidle-psci-domain.c | 21 +++++++++++++++++++++ > > > > drivers/cpuidle/cpuidle-psci.h | 6 ++++++ > > > > 2 files changed, 27 insertions(+) > > > > > > > > diff --git a/drivers/cpuidle/cpuidle-psci-domain.c b/drivers/cpuidle/cpuidle-psci-domain.c > > > > index 3f5143ccc3e0..7429fd7626a1 100644 > > > > --- a/drivers/cpuidle/cpuidle-psci-domain.c > > > > +++ b/drivers/cpuidle/cpuidle-psci-domain.c > > > > @@ -9,9 +9,11 @@ > > > > > > > > #define pr_fmt(fmt) "CPUidle PSCI: " fmt > > > > > > > > +#include <linux/cpu.h> > > > > #include <linux/device.h> > > > > #include <linux/kernel.h> > > > > #include <linux/pm_domain.h> > > > > +#include <linux/pm_runtime.h> > > > > #include <linux/psci.h> > > > > #include <linux/slab.h> > > > > #include <linux/string.h> > > > > @@ -279,3 +281,22 @@ static int __init psci_idle_init_domains(void) > > > > return ret; > > > > } > > > > subsys_initcall(psci_idle_init_domains); > > > > + > > > > +struct device *psci_dt_attach_cpu(int cpu) > > > > +{ > > > > + struct device *dev; > > > > + > > > > + /* Currently limit the hierarchical topology to be used in OSI mode. */ > > > > + if (!psci_has_osi_support()) > > > > + return NULL; > > > > + > > > > + dev = dev_pm_domain_attach_by_name(get_cpu_device(cpu), "psci"); > > > > > > This clarifies the need for the fixed name. But why not just go by index 0 > > > as the consumer of these psci power-domains will have only one power domain > > > entry. Why do we need this name compulsory ? > > > > The idea is to be future proof. If I recall correctly, the CPU node on > > some QCOM SoCs may also have "CPR" PM domain specified, thus > > "multiple" power-domains could be specified. > > > > I am sure we don't want to mx-n-match any power domain provider with > psci. And also I expect in these above mentioned cases, there won't be any > psci power domains. > > > In any case, using "psci" doesn't really hurt, right? > > > > Doesn't but I don't see need for one as only one should exist, as mentioned > above we don't want mix-n-match with psci ever. Not sure I get your point, sorry. The CPU could very well be attached to more than one power-domain. Of course not multiple "PSCI power-domains". One could be an PSCI power domain and another one could be the QCOM CPR (Core power reduction) power domain. Have a look at these binding, there are already upstream, perhaps that clarifies this? Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt > > > > Further, it's specified as > > > optional in the generic binding, do we make it "required" for this psci > > > idle states binding anywhere that I missed ? > > > > Good point! Unless you tell me differently, I will update the DT doc > > to clarify this is "required". > > > > No but why is my question ? We don't have to. If firmware/DT wants to > specify the name, sure. But it must remain optional IMO. According the QCOM CPR case, we need a way to distinguish what power domain we should attach the CPU to. If we don't use power-domain-names to do that, what else should we use? Kind regards Uffe _______________________________________________ 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:[~2019-10-28 7:36 UTC|newest] Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-10 11:39 [PATCH 00/13] cpuidle: psci: Support hierarchical CPU arrangement Ulf Hansson 2019-10-10 11:39 ` Ulf Hansson 2019-10-10 11:39 ` [PATCH 01/13] cpuidle: psci: Fix potential access to unmapped memory Ulf Hansson 2019-10-10 11:39 ` Ulf Hansson 2019-10-18 9:38 ` Lorenzo Pieralisi 2019-10-18 9:38 ` Lorenzo Pieralisi 2019-10-18 9:51 ` Ulf Hansson 2019-10-18 9:51 ` Ulf Hansson 2019-10-18 10:03 ` Lorenzo Pieralisi 2019-10-18 10:03 ` Lorenzo Pieralisi 2019-10-18 10:29 ` Ulf Hansson 2019-10-18 10:29 ` Ulf Hansson 2019-10-18 16:47 ` Lorenzo Pieralisi 2019-10-18 16:47 ` Lorenzo Pieralisi 2019-10-24 15:18 ` [PATCH] cpuidle: psci: Align psci_power_state count with idle state count Sudeep Holla 2019-10-24 15:18 ` Sudeep Holla 2019-10-24 16:10 ` Ulf Hansson 2019-10-24 16:10 ` Ulf Hansson 2019-10-27 2:20 ` Sudeep Holla 2019-10-27 2:20 ` Sudeep Holla 2019-10-10 11:39 ` [PATCH 02/13] dt: psci: Update DT bindings to support hierarchical PSCI states Ulf Hansson 2019-10-10 11:39 ` Ulf Hansson 2019-10-24 15:26 ` Sudeep Holla 2019-10-24 15:26 ` Sudeep Holla 2019-10-24 16:23 ` Ulf Hansson 2019-10-24 16:23 ` Ulf Hansson 2019-10-10 11:39 ` [PATCH 03/13] firmware: psci: Export functions to manage the OSI mode Ulf Hansson 2019-10-10 11:39 ` Ulf Hansson 2019-10-24 15:27 ` Sudeep Holla 2019-10-24 15:27 ` Sudeep Holla 2019-10-10 11:39 ` [PATCH 04/13] of: base: Add of_get_cpu_state_node() to get idle states for a CPU node Ulf Hansson 2019-10-10 11:39 ` Ulf Hansson 2019-10-24 15:28 ` Sudeep Holla 2019-10-24 15:28 ` Sudeep Holla 2019-10-10 11:39 ` [PATCH 05/13] cpuidle: dt: Support hierarchical CPU idle states Ulf Hansson 2019-10-10 11:39 ` Ulf Hansson 2019-10-24 15:30 ` Sudeep Holla 2019-10-24 15:30 ` Sudeep Holla 2019-10-10 11:39 ` [PATCH 06/13] cpuidle: psci: Simplify OF parsing of CPU idle state nodes Ulf Hansson 2019-10-10 11:39 ` Ulf Hansson 2019-10-24 15:36 ` Sudeep Holla 2019-10-24 15:36 ` Sudeep Holla 2019-10-24 16:33 ` Ulf Hansson 2019-10-24 16:33 ` Ulf Hansson 2019-10-27 2:24 ` Sudeep Holla 2019-10-27 2:24 ` Sudeep Holla 2019-10-10 11:39 ` [PATCH 07/13] cpuidle: psci: Support hierarchical CPU idle states Ulf Hansson 2019-10-10 11:39 ` Ulf Hansson 2019-10-24 15:39 ` Sudeep Holla 2019-10-24 15:39 ` Sudeep Holla 2019-10-10 11:39 ` [PATCH 08/13] cpuidle: psci: Prepare to use OS initiated suspend mode via PM domains Ulf Hansson 2019-10-10 11:39 ` Ulf Hansson 2019-10-24 15:42 ` Sudeep Holla 2019-10-24 15:42 ` Sudeep Holla 2019-10-24 17:01 ` Ulf Hansson 2019-10-24 17:01 ` Ulf Hansson 2019-10-10 11:39 ` [PATCH 09/13] cpuidle: psci: Add support for PM domains by using genpd Ulf Hansson 2019-10-10 11:39 ` Ulf Hansson 2019-10-24 15:46 ` Sudeep Holla 2019-10-24 15:46 ` Sudeep Holla 2019-10-10 11:39 ` [PATCH 10/13] cpuidle: psci: Add a helper to attach a CPU to its PM domain Ulf Hansson 2019-10-10 11:39 ` Ulf Hansson 2019-10-24 16:31 ` Sudeep Holla 2019-10-24 16:31 ` Sudeep Holla 2019-10-24 16:47 ` Ulf Hansson 2019-10-24 16:47 ` Ulf Hansson 2019-10-27 2:30 ` Sudeep Holla 2019-10-27 2:30 ` Sudeep Holla 2019-10-28 7:35 ` Ulf Hansson [this message] 2019-10-28 7:35 ` Ulf Hansson 2019-10-28 7:49 ` Sudeep Holla 2019-10-28 7:49 ` Sudeep Holla 2019-10-28 9:45 ` Ulf Hansson 2019-10-28 9:45 ` Ulf Hansson 2019-10-29 5:34 ` Sudeep Holla 2019-10-29 5:34 ` Sudeep Holla 2019-10-29 9:44 ` Niklas Cassel 2019-10-29 9:44 ` Niklas Cassel 2019-10-30 0:50 ` Sudeep Holla 2019-10-30 0:50 ` Sudeep Holla 2019-10-10 11:39 ` [PATCH 11/13] cpuidle: psci: Attach CPU devices to their PM domains Ulf Hansson 2019-10-10 11:39 ` Ulf Hansson 2019-10-24 16:35 ` Sudeep Holla 2019-10-24 16:35 ` Sudeep Holla 2019-10-24 16:55 ` Ulf Hansson 2019-10-24 16:55 ` Ulf Hansson 2019-10-27 2:32 ` Sudeep Holla 2019-10-27 2:32 ` Sudeep Holla 2019-10-10 11:39 ` [PATCH 12/13] cpuidle: psci: Manage runtime PM in the idle path Ulf Hansson 2019-10-10 11:39 ` Ulf Hansson 2019-10-24 16:32 ` Sudeep Holla 2019-10-24 16:32 ` Sudeep Holla 2019-10-24 17:00 ` Ulf Hansson 2019-10-24 17:00 ` Ulf Hansson 2019-10-25 8:28 ` Lorenzo Pieralisi 2019-10-25 8:28 ` Lorenzo Pieralisi 2019-10-25 14:13 ` Ulf Hansson 2019-10-25 14:13 ` Ulf Hansson 2019-10-27 2:34 ` Sudeep Holla 2019-10-27 2:34 ` Sudeep Holla 2019-10-28 22:40 ` Ulf Hansson 2019-10-28 22:40 ` Ulf Hansson 2019-10-10 11:39 ` [PATCH 13/13] arm64: dts: Convert to the hierarchical CPU topology layout for MSM8916 Ulf Hansson 2019-10-10 11:39 ` Ulf Hansson 2019-10-24 16:41 ` Sudeep Holla 2019-10-24 16:41 ` Sudeep Holla 2019-10-24 17:03 ` Ulf Hansson 2019-10-24 17:03 ` Ulf Hansson 2019-10-18 8:10 ` [PATCH 00/13] cpuidle: psci: Support hierarchical CPU arrangement Ulf Hansson 2019-10-18 8:10 ` Ulf Hansson
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=CAPDyKFr1LJ_HP1kcfMh7LE5j7nUT9KzH4vhdCSEE9wg6RfYErQ@mail.gmail.com \ --to=ulf.hansson@linaro.org \ --cc=Lorenzo.Pieralisi@arm.com \ --cc=bjorn.andersson@linaro.org \ --cc=daniel.lezcano@linaro.org \ --cc=ilina@codeaurora.org \ --cc=khilman@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=rjw@rjwysocki.net \ --cc=robh+dt@kernel.org \ --cc=sboyd@kernel.org \ --cc=sudeep.holla@arm.com \ --cc=vincent.guittot@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.