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 <Lorenzo.Pieralisi@arm.com>, Juri Lelli <Juri.Lelli@arm.com>, khilman@kernel.org, sboyd@codeaurora.org, linux-pm@vger.kernel.org, rjw@rjwysocki.net, Axel Haslam <ahaslam+renesas@baylibre.com>, Marc Titinger <mtitinger+renesas@baylibre.com>, Brendan Jackman <Brendan.Jackman@arm.com>, linux-arm-msm@vger.kernel.org, andy.gross@linaro.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states Date: Wed, 10 Aug 2016 10:40:34 -0600 [thread overview] Message-ID: <20160810164034.GA1401@linaro.org> (raw) In-Reply-To: <99e35b6c-6698-6d27-f4d7-fa032796869e@arm.com> Hi Sudeep, On Wed, Aug 10 2016 at 09:15 -0600, Sudeep Holla wrote: >Hi Lina, > >I have few concerns mainly due to the lack of description and not the >binding per say. > >On 05/08/16 00:04, Lina Iyer wrote: >>From: Axel Haslam <ahaslam+renesas@baylibre.com> >> >>Update DT bindings to describe idle states of PM domains. >> >>Cc: <devicetree@vger.kernel.org> >>Signed-off-by: Marc Titinger <mtitinger+renesas@baylibre.com> >>Signed-off-by: Lina Iyer <lina.iyer@linaro.org> >>[Lina: Added state properties, removed state names, wakeup-latency, >>added of_pm_genpd_init() API, pruned commit text] >>Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> >>[Ulf: Moved around code to make it compile properly, rebased on top of multiple state support] >>--- >> .../devicetree/bindings/power/power_domain.txt | 57 ++++++++++++++++++++++ >> 1 file changed, 57 insertions(+) >> >>diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt >>index 025b5e7..4960486 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]. >>+ > >So I assume these can be used for the genpd states. Either we rename >it domain-power-states or make it clear that these domain-idle-states >can also represent the power-states for normal devices. > These are the domains' idle states. These states are only used when the domain goes into idle, not when the domain is active. These are not power states that the domain can operate on either. Hence the idle-state moniker. Also, the bindings to describe the state are the same as arm,idle-state. It made sense to call these domain idle states instead of domain-power-states. >> Example: >> >> power: power-controller@12340000 { >>@@ -59,6 +63,57 @@ The nodes above define two power controllers: 'parent' and 'child'. >> Domains created by the 'child' power controller are subdomains of '0' power >> domain provided by the 'parent' power controller. >> >>+Example 3: ARM v7 style CPU PM domains (Linux domain controller) >>+ >>+ cpus { >>+ #address-cells = <1>; >>+ #size-cells = <0>; >>+ >>+ CPU0: cpu@0 { >>+ device_type = "cpu"; >>+ compatible = "arm,cortex-a7", "arm,armv7"; >>+ reg = <0x0>; >>+ power-domains = <&a7_pd>; > >This example doesn't consider how do we deal with the presence off >cpu-idle-states property in CPU nodes. > I can amend the example. But to answer your underlying question, they will exist as separate properties. >IMO we need move even the cpu/core level idle states into its own power >domain. It also helps to solve other usecases like PMU, debug/coresight >devices attached to the core power domain(in most of the cases) while >they may be in separate PD like PMUs on OMAP. That will help OS whether >to save/restore the states on idle-entry. > This idea was brought up by Kevin earlier in the discussions, but we shelved it for a later date. >In [PATCH v3 15/15] ARM64: dts: Define CPU power domain for MSM8916, the >idle-states are split across the cpu cpu-idle-states and pd >domain-idle-states property. That looks like a really mess to me. > It is pretty clear that CPUs cannot not define the domain idle states. Domains define their own idle states. Just as you mention above. CPU is just a single component in its domain. There may be other devices like PMUs, Coresights etc that also may have a say in the idle state the domain may be put in, when the devices are idle. As such, adding domain idle states to the CPU's idle state property is not appropriate. Our kernel has runtime PM for devices and then there is CPUidle, both are diverging without one knowing about the other. We have to start unifying them inorder to have better holistic power management in the SoC. To that regard, we have to start imagining CPUs as just another device, albeit a special device. But for our purposes in determining domain idle state, it will just be a device attached to the domain. >We need to have all the idle state information at one place and in this >case PD seems more appropriate instead of splitting them across. > That approach isn't correct. Where will we put the idle states of other devices that are also part of the domain? We are thinking about a model, where every device defines its own idle states and we define relationships between those idle states and their parents' idle states. Ofcourse, devices don't have idle states today, but that is something we have been pondering over. >We can also keep the code clean and not break compatibility. Whenever >both PD and CPU contains idle-states, PD must take precedence. > Why? The CPU and PD states are orthogonal. While the PD state is dependent on the CPU state, the latter is not true. Devices determine their own states. Based on the individual device states, we then determine the state of the parent and bubble up on the hierarchy. >Also these needs to be documented clearly in the binding. > >>+ }; >>+ >>+ CPU1: cpu@1 { >>+ device_type = "cpu"; >>+ compatible = "arm,cortex-a15", "arm,armv7"; >>+ reg = <0x0>; >>+ power-domains = <&a15_pd>; >>+ }; >>+ }; >>+ >>+ pm-domains { >>+ a15_pd: a15_pd { >>+ /* will have A15 platform ARM_PD_METHOD_OF_DECLARE*/ > >the above comment make no sense in the binding document, remove it > Yup. Will remove. 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 v3 02/15] dt/bindings: Update binding for PM domain idle states Date: Wed, 10 Aug 2016 10:40:34 -0600 [thread overview] Message-ID: <20160810164034.GA1401@linaro.org> (raw) In-Reply-To: <99e35b6c-6698-6d27-f4d7-fa032796869e@arm.com> Hi Sudeep, On Wed, Aug 10 2016 at 09:15 -0600, Sudeep Holla wrote: >Hi Lina, > >I have few concerns mainly due to the lack of description and not the >binding per say. > >On 05/08/16 00:04, Lina Iyer wrote: >>From: Axel Haslam <ahaslam+renesas@baylibre.com> >> >>Update DT bindings to describe idle states of PM domains. >> >>Cc: <devicetree@vger.kernel.org> >>Signed-off-by: Marc Titinger <mtitinger+renesas@baylibre.com> >>Signed-off-by: Lina Iyer <lina.iyer@linaro.org> >>[Lina: Added state properties, removed state names, wakeup-latency, >>added of_pm_genpd_init() API, pruned commit text] >>Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> >>[Ulf: Moved around code to make it compile properly, rebased on top of multiple state support] >>--- >> .../devicetree/bindings/power/power_domain.txt | 57 ++++++++++++++++++++++ >> 1 file changed, 57 insertions(+) >> >>diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt >>index 025b5e7..4960486 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]. >>+ > >So I assume these can be used for the genpd states. Either we rename >it domain-power-states or make it clear that these domain-idle-states >can also represent the power-states for normal devices. > These are the domains' idle states. These states are only used when the domain goes into idle, not when the domain is active. These are not power states that the domain can operate on either. Hence the idle-state moniker. Also, the bindings to describe the state are the same as arm,idle-state. It made sense to call these domain idle states instead of domain-power-states. >> Example: >> >> power: power-controller at 12340000 { >>@@ -59,6 +63,57 @@ The nodes above define two power controllers: 'parent' and 'child'. >> Domains created by the 'child' power controller are subdomains of '0' power >> domain provided by the 'parent' power controller. >> >>+Example 3: ARM v7 style CPU PM domains (Linux domain controller) >>+ >>+ cpus { >>+ #address-cells = <1>; >>+ #size-cells = <0>; >>+ >>+ CPU0: cpu at 0 { >>+ device_type = "cpu"; >>+ compatible = "arm,cortex-a7", "arm,armv7"; >>+ reg = <0x0>; >>+ power-domains = <&a7_pd>; > >This example doesn't consider how do we deal with the presence off >cpu-idle-states property in CPU nodes. > I can amend the example. But to answer your underlying question, they will exist as separate properties. >IMO we need move even the cpu/core level idle states into its own power >domain. It also helps to solve other usecases like PMU, debug/coresight >devices attached to the core power domain(in most of the cases) while >they may be in separate PD like PMUs on OMAP. That will help OS whether >to save/restore the states on idle-entry. > This idea was brought up by Kevin earlier in the discussions, but we shelved it for a later date. >In [PATCH v3 15/15] ARM64: dts: Define CPU power domain for MSM8916, the >idle-states are split across the cpu cpu-idle-states and pd >domain-idle-states property. That looks like a really mess to me. > It is pretty clear that CPUs cannot not define the domain idle states. Domains define their own idle states. Just as you mention above. CPU is just a single component in its domain. There may be other devices like PMUs, Coresights etc that also may have a say in the idle state the domain may be put in, when the devices are idle. As such, adding domain idle states to the CPU's idle state property is not appropriate. Our kernel has runtime PM for devices and then there is CPUidle, both are diverging without one knowing about the other. We have to start unifying them inorder to have better holistic power management in the SoC. To that regard, we have to start imagining CPUs as just another device, albeit a special device. But for our purposes in determining domain idle state, it will just be a device attached to the domain. >We need to have all the idle state information at one place and in this >case PD seems more appropriate instead of splitting them across. > That approach isn't correct. Where will we put the idle states of other devices that are also part of the domain? We are thinking about a model, where every device defines its own idle states and we define relationships between those idle states and their parents' idle states. Ofcourse, devices don't have idle states today, but that is something we have been pondering over. >We can also keep the code clean and not break compatibility. Whenever >both PD and CPU contains idle-states, PD must take precedence. > Why? The CPU and PD states are orthogonal. While the PD state is dependent on the CPU state, the latter is not true. Devices determine their own states. Based on the individual device states, we then determine the state of the parent and bubble up on the hierarchy. >Also these needs to be documented clearly in the binding. > >>+ }; >>+ >>+ CPU1: cpu at 1 { >>+ device_type = "cpu"; >>+ compatible = "arm,cortex-a15", "arm,armv7"; >>+ reg = <0x0>; >>+ power-domains = <&a15_pd>; >>+ }; >>+ }; >>+ >>+ pm-domains { >>+ a15_pd: a15_pd { >>+ /* will have A15 platform ARM_PD_METHOD_OF_DECLARE*/ > >the above comment make no sense in the binding document, remove it > Yup. Will remove. Thanks, Lina
next prev parent reply other threads:[~2016-08-10 16:40 UTC|newest] Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-08-04 23:04 [PATCH v3 00/15] PM: SoC idle support using PM domains Lina Iyer 2016-08-04 23:04 ` Lina Iyer 2016-08-04 23:04 ` [PATCH v3 01/15] PM / Domains: Allow domain power states to be read from DT Lina Iyer 2016-08-04 23:04 ` Lina Iyer 2016-08-04 23:04 ` [PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states Lina Iyer 2016-08-04 23:04 ` Lina Iyer 2016-08-09 23:55 ` Rob Herring 2016-08-09 23:55 ` Rob Herring 2016-08-10 15:14 ` Sudeep Holla 2016-08-10 15:14 ` Sudeep Holla 2016-08-10 16:40 ` Lina Iyer [this message] 2016-08-10 16:40 ` Lina Iyer [not found] ` <20160810164034.GA1401-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2016-08-10 18:09 ` Sudeep Holla 2016-08-10 18:09 ` Sudeep Holla 2016-08-10 18:13 ` Sudeep Holla 2016-08-10 18:13 ` Sudeep Holla [not found] ` <5e59874c-bbb7-270a-199c-da1ff5932554-5wv7dgnIgG8@public.gmane.org> 2016-08-11 21:10 ` Lina Iyer 2016-08-11 21:10 ` Lina Iyer [not found] ` <20160811211023.GC1401-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2016-08-12 9:47 ` Brendan Jackman 2016-08-12 9:47 ` Brendan Jackman 2016-08-12 10:08 ` Sudeep Holla 2016-08-12 10:08 ` Sudeep Holla 2016-08-15 16:08 ` Lina Iyer 2016-08-15 16:08 ` Lina Iyer 2016-08-15 16:14 ` Sudeep Holla 2016-08-15 16:14 ` Sudeep Holla 2016-08-15 22:40 ` Lina Iyer 2016-08-15 22:40 ` Lina Iyer [not found] ` <20160815224014.GF1401-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2016-08-16 8:34 ` Brendan Jackman 2016-08-16 8:34 ` Brendan Jackman 2016-08-16 8:41 ` Brendan Jackman 2016-08-16 8:41 ` Brendan Jackman 2016-08-16 9:19 ` Sudeep Holla 2016-08-16 9:19 ` Sudeep Holla 2016-08-12 12:35 ` Brendan Jackman 2016-08-12 12:35 ` Brendan Jackman 2016-08-15 16:06 ` Lina Iyer 2016-08-15 16:06 ` Lina Iyer 2016-08-19 18:10 ` Kevin Hilman 2016-08-19 18:10 ` Kevin Hilman 2016-08-24 14:07 ` Sudeep Holla 2016-08-24 14:07 ` Sudeep Holla [not found] ` <1470351902-43103-3-git-send-email-lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2016-08-24 13:48 ` [RFC 0/6] Illustration of using domain-idle-states for CPU " Brendan Jackman 2016-08-24 13:48 ` [RFC 1/6] cpuidle: Rename cpuidle_get_{cpu->dev}_driver Brendan Jackman 2016-08-24 13:48 ` [RFC 2/6] cpuidle: Add public funcion to get driver from CPU index Brendan Jackman [not found] ` <20160824134822.3591-1-brendan.jackman-5wv7dgnIgG8@public.gmane.org> 2016-08-24 13:48 ` [RFC 3/6] cpuidle: Add device_node pointer in cpuidle_state Brendan Jackman 2016-08-24 13:48 ` [RFC 6/6] arm64: dts: Add domain-idle-states for Juno r0 power domains Brendan Jackman 2016-08-24 13:48 ` [RFC 4/6] cpuidle: dt: Add support for reading states from " Brendan Jackman 2016-08-24 13:48 ` [RFC 5/6] arm64: dts: Add Juno r0 CPU power domain tree Brendan Jackman 2016-08-04 23:04 ` [PATCH v3 03/15] PM / Domains: Abstract genpd locking Lina Iyer 2016-08-04 23:04 ` Lina Iyer 2016-08-04 23:04 ` [PATCH v3 04/15] PM / Domains: Support IRQ safe PM domains Lina Iyer 2016-08-04 23:04 ` Lina Iyer 2016-08-04 23:04 ` [PATCH v3 05/15] PM / doc: Update device documentation for devices in " Lina Iyer 2016-08-04 23:04 ` Lina Iyer 2016-08-04 23:04 ` [PATCH v3 06/15] PM / cpu_domains: Setup PM domains for CPUs/clusters Lina Iyer 2016-08-04 23:04 ` Lina Iyer 2016-08-04 23:04 ` [PATCH v3 07/15] ARM: cpuidle: Add runtime PM support for CPUs Lina Iyer 2016-08-04 23:04 ` Lina Iyer 2016-08-04 23:04 ` [PATCH v3 08/15] timer: Export next wake up of a CPU Lina Iyer 2016-08-04 23:04 ` Lina Iyer 2016-08-04 23:04 ` [PATCH v3 09/15] PM / cpu_domains: Add PM Domain governor for CPUs Lina Iyer 2016-08-04 23:04 ` Lina Iyer 2016-08-04 23:04 ` [PATCH v3 10/15] doc / cpu_domains: Describe CPU PM domains setup and governor Lina Iyer 2016-08-04 23:04 ` Lina Iyer 2016-08-04 23:04 ` [PATCH v3 11/15] drivers: firmware: psci: Allow OS Initiated suspend mode Lina Iyer 2016-08-04 23:04 ` Lina Iyer 2016-08-04 23:04 ` [PATCH v3 12/15] drivers: firmware: psci: Support cluster idle states for OS-Initiated Lina Iyer 2016-08-04 23:04 ` Lina Iyer 2016-08-04 23:05 ` [PATCH v3 13/15] dt/bindings: Add PSCI OS-Initiated PM Domains bindings Lina Iyer 2016-08-04 23:05 ` Lina Iyer 2016-08-05 14:44 ` Lina Iyer 2016-08-05 14:44 ` Lina Iyer 2016-08-04 23:05 ` [PATCH v3 14/15] ARM64: dts: Add PSCI cpuidle support for MSM8916 Lina Iyer 2016-08-04 23:05 ` Lina Iyer [not found] ` <1470351902-43103-1-git-send-email-lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2016-08-04 23:05 ` [PATCH v3 15/15] ARM64: dts: Define CPU power domain " Lina Iyer 2016-08-04 23:05 ` Lina Iyer 2016-08-10 15:27 ` Sudeep Holla 2016-08-10 15:27 ` Sudeep Holla 2016-08-10 17:35 ` Lina Iyer 2016-08-10 17:35 ` Lina Iyer 2016-08-11 9:30 ` Sudeep Holla 2016-08-11 9:30 ` Sudeep Holla
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=20160810164034.GA1401@linaro.org \ --to=lina.iyer@linaro.org \ --cc=Brendan.Jackman@arm.com \ --cc=Juri.Lelli@arm.com \ --cc=Lorenzo.Pieralisi@arm.com \ --cc=ahaslam+renesas@baylibre.com \ --cc=andy.gross@linaro.org \ --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=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.