From: Lina Iyer <lina.iyer@linaro.org> To: Sudeep Holla <sudeep.holla@arm.com> Cc: devicetree@vger.kernel.org, ulf.hansson@linaro.org, lorenzo.pieralisi@arm.com, Juri.Lelli@arm.com, khilman@kernel.org, sboyd@codeaurora.org, linux-pm@vger.kernel.org, rjw@rjwysocki.net, Marc Titinger <mtitinger+renesas@baylibre.com>, brendan.jackman@arm.com, linux-arm-msm@vger.kernel.org, andy.gross@linaro.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 5/8] dt/bindings: Update binding for PM domain idle states Date: Mon, 10 Oct 2016 10:43:42 -0600 [thread overview] Message-ID: <20161010164342.GC44885@linaro.org> (raw) In-Reply-To: <4e55d6ad-8de7-72d7-7512-5e4ff2aabc79@arm.com> On Mon, Oct 10 2016 at 09:45 -0600, Sudeep Holla wrote: > > >On 07/10/16 23:36, Lina Iyer wrote: >>Update DT bindings to describe idle states of PM domains. >> >>This patch is based on the original patch by Marc Titinger. >> >>Cc: <devicetree@vger.kernel.org> >>Signed-off-by: Marc Titinger <mtitinger+renesas@baylibre.com> >>Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> >>Signed-off-by: Lina Iyer <lina.iyer@linaro.org> >>Acked-by: Rob Herring <robh@kernel.org> >>--- >> .../devicetree/bindings/power/power_domain.txt | 38 ++++++++++++++++++++++ >> 1 file changed, 38 insertions(+) >> >>diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt >>index 025b5e7..7f8f27e 100644 >>--- a/Documentation/devicetree/bindings/power/power_domain.txt >>+++ b/Documentation/devicetree/bindings/power/power_domain.txt >>@@ -29,6 +29,10 @@ Optional properties: >> specified by this binding. More details about power domain specifier are >> available in the next section. >> >>+- domain-idle-states : A phandle of an idle-state that shall be soaked into a >>+ generic domain power state. The idle state definitions are >>+ compatible with arm,idle-state specified in [1]. >>+ > >Please do add the following details to the binding. IMO, this binding is >not complete in terms of specification as there are few open questions: > >1. What not define a standard compatible instead of "arm,idle-state" ? > I agree it can be used, but as part of this *generic* binding, IMO > it's better to have something generic and can be used by devices. > Otherwise, this binding becomes CPU specific, that too ARM CPU > specific. > We had gone down this path of having a separate DT bindings for domains that is not arm,idle-state. See RFC patches. But the binding did closely match this and it so was suggested that we use arm,idle-state which is already defined. >2. Now taking CPU as a special device, how does this co-exist with the > cpu-idle-states ? Better to have some description may be in the ARM > CPU idle binding document(not here of-course) > The is a binding for a generic PM domain. This has no bearing on the CPU or its idle states. Its just that the data is compatible with arm,idle-state. >3. I still haven't seen any explanation for not considering complete > hierarchical power domain representation which was raised in earlier > versions. I had provided example for the proposal. I just saw them > already in use in the upstream kernel by Renasas. e.g.: > arch/arm/boot/dts/r8a73a4.dtsi > Hierarchical power domains have been available for few years in DT. The OF features of domains have always supported it. Platforms are free to define domains in hierarchy they seem fit for their SoCs. This is a feature that is available today and is not being modified in these patches. It will be creating confusion if I talk about hierarchical domains which are obvious and irrelevant to this series. > How does that fit with your proposal, though you have not made one > yet for CPUs in this binding ? In the above file, CPUs have either > own power domain inside the L2 one which is cluster level power > domain. > Again, this series is not about the CPUs. This is about adding features to genpd that may be used in other contexts including cpuidle in the future. >One must be able to get answers to these above questions with this >binding. Until then it's *incomplete* though it may be correct. > I have always tried to answer all your questions. If anything remains unclarified pls. bring it up. Thanks, Lina
WARNING: multiple messages have this Message-ID (diff)
From: lina.iyer@linaro.org (Lina Iyer) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v2 5/8] dt/bindings: Update binding for PM domain idle states Date: Mon, 10 Oct 2016 10:43:42 -0600 [thread overview] Message-ID: <20161010164342.GC44885@linaro.org> (raw) In-Reply-To: <4e55d6ad-8de7-72d7-7512-5e4ff2aabc79@arm.com> On Mon, Oct 10 2016 at 09:45 -0600, Sudeep Holla wrote: > > >On 07/10/16 23:36, Lina Iyer wrote: >>Update DT bindings to describe idle states of PM domains. >> >>This patch is based on the original patch by Marc Titinger. >> >>Cc: <devicetree@vger.kernel.org> >>Signed-off-by: Marc Titinger <mtitinger+renesas@baylibre.com> >>Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> >>Signed-off-by: Lina Iyer <lina.iyer@linaro.org> >>Acked-by: Rob Herring <robh@kernel.org> >>--- >> .../devicetree/bindings/power/power_domain.txt | 38 ++++++++++++++++++++++ >> 1 file changed, 38 insertions(+) >> >>diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt >>index 025b5e7..7f8f27e 100644 >>--- a/Documentation/devicetree/bindings/power/power_domain.txt >>+++ b/Documentation/devicetree/bindings/power/power_domain.txt >>@@ -29,6 +29,10 @@ Optional properties: >> specified by this binding. More details about power domain specifier are >> available in the next section. >> >>+- domain-idle-states : A phandle of an idle-state that shall be soaked into a >>+ generic domain power state. The idle state definitions are >>+ compatible with arm,idle-state specified in [1]. >>+ > >Please do add the following details to the binding. IMO, this binding is >not complete in terms of specification as there are few open questions: > >1. What not define a standard compatible instead of "arm,idle-state" ? > I agree it can be used, but as part of this *generic* binding, IMO > it's better to have something generic and can be used by devices. > Otherwise, this binding becomes CPU specific, that too ARM CPU > specific. > We had gone down this path of having a separate DT bindings for domains that is not arm,idle-state. See RFC patches. But the binding did closely match this and it so was suggested that we use arm,idle-state which is already defined. >2. Now taking CPU as a special device, how does this co-exist with the > cpu-idle-states ? Better to have some description may be in the ARM > CPU idle binding document(not here of-course) > The is a binding for a generic PM domain. This has no bearing on the CPU or its idle states. Its just that the data is compatible with arm,idle-state. >3. I still haven't seen any explanation for not considering complete > hierarchical power domain representation which was raised in earlier > versions. I had provided example for the proposal. I just saw them > already in use in the upstream kernel by Renasas. e.g.: > arch/arm/boot/dts/r8a73a4.dtsi > Hierarchical power domains have been available for few years in DT. The OF features of domains have always supported it. Platforms are free to define domains in hierarchy they seem fit for their SoCs. This is a feature that is available today and is not being modified in these patches. It will be creating confusion if I talk about hierarchical domains which are obvious and irrelevant to this series. > How does that fit with your proposal, though you have not made one > yet for CPUs in this binding ? In the above file, CPUs have either > own power domain inside the L2 one which is cluster level power > domain. > Again, this series is not about the CPUs. This is about adding features to genpd that may be used in other contexts including cpuidle in the future. >One must be able to get answers to these above questions with this >binding. Until then it's *incomplete* though it may be correct. > I have always tried to answer all your questions. If anything remains unclarified pls. bring it up. Thanks, Lina
next prev parent reply other threads:[~2016-10-10 16:43 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-10-07 22:36 [PATCH v2 0/8] PM / Domains: DT support for domain idle states & atomic PM domains Lina Iyer 2016-10-07 22:36 ` Lina Iyer 2016-10-07 22:36 ` [PATCH v2 1/8] PM / Domains: Make genpd state allocation dynamic Lina Iyer 2016-10-07 22:36 ` Lina Iyer 2016-10-10 8:40 ` Ulf Hansson 2016-10-10 8:40 ` Ulf Hansson 2016-10-10 15:05 ` Lina Iyer 2016-10-10 15:05 ` Lina Iyer 2016-10-07 22:36 ` [PATCH v2 2/8] PM / Domain: Add residency property to genpd states Lina Iyer 2016-10-07 22:36 ` Lina Iyer 2016-10-07 22:36 ` [PATCH v2 3/8] PM / Domains: Allow domain power states to be read from DT Lina Iyer 2016-10-07 22:36 ` Lina Iyer 2016-10-10 10:01 ` Ulf Hansson 2016-10-10 10:01 ` Ulf Hansson 2016-10-10 15:03 ` Lina Iyer 2016-10-10 15:03 ` Lina Iyer 2016-10-10 21:24 ` Ulf Hansson 2016-10-10 21:24 ` Ulf Hansson 2016-10-07 22:36 ` [PATCH v2 4/8] PM / Domains: Save the fwnode in genpd_power_state Lina Iyer 2016-10-07 22:36 ` Lina Iyer 2016-10-10 10:03 ` Ulf Hansson 2016-10-10 10:03 ` Ulf Hansson 2016-10-07 22:36 ` [PATCH v2 5/8] dt/bindings: Update binding for PM domain idle states Lina Iyer 2016-10-07 22:36 ` Lina Iyer 2016-10-10 15:45 ` Sudeep Holla 2016-10-10 15:45 ` Sudeep Holla 2016-10-10 16:43 ` Lina Iyer [this message] 2016-10-10 16:43 ` Lina Iyer [not found] ` <20161010164342.GC44885-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2016-10-10 17:13 ` Sudeep Holla 2016-10-10 17:13 ` Sudeep Holla 2016-10-10 22:13 ` Lina Iyer 2016-10-10 22:13 ` Lina Iyer 2016-10-11 11:29 ` Sudeep Holla 2016-10-11 11:29 ` Sudeep Holla 2016-10-10 17:19 ` Sudeep Holla 2016-10-10 17:19 ` Sudeep Holla 2016-10-07 22:36 ` [PATCH v2 6/8] PM / Domains: Abstract genpd locking Lina Iyer 2016-10-07 22:36 ` Lina Iyer 2016-10-07 22:37 ` [PATCH v2 7/8] PM / Domains: Support IRQ safe PM domains Lina Iyer 2016-10-07 22:37 ` Lina Iyer 2016-10-10 11:04 ` Ulf Hansson 2016-10-10 11:04 ` Ulf Hansson 2016-10-07 22:37 ` [PATCH v2 8/8] PM / doc: Update device documentation for devices in " Lina Iyer 2016-10-07 22:37 ` Lina Iyer 2016-10-10 11:06 ` Ulf Hansson 2016-10-10 11:06 ` 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=20161010164342.GC44885@linaro.org \ --to=lina.iyer@linaro.org \ --cc=Juri.Lelli@arm.com \ --cc=andy.gross@linaro.org \ --cc=brendan.jackman@arm.com \ --cc=devicetree@vger.kernel.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=lorenzo.pieralisi@arm.com \ --cc=mtitinger+renesas@baylibre.com \ --cc=rjw@rjwysocki.net \ --cc=sboyd@codeaurora.org \ --cc=sudeep.holla@arm.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.