From: Sudeep Holla <sudeep.holla@arm.com> To: Lina Iyer <lina.iyer@linaro.org> Cc: devicetree@vger.kernel.org, ulf.hansson@linaro.org, lorenzo.pieralisi@arm.com, Juri.Lelli@arm.com, khilman@kernel.org, sboyd@codeaurora.org, linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org, rjw@rjwysocki.net, Marc Titinger <mtitinger+renesas@baylibre.com>, brendan.jackman@arm.com, Sudeep Holla <sudeep.holla@arm.com>, 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: Tue, 11 Oct 2016 12:29:30 +0100 [thread overview] Message-ID: <5a50adda-5c34-2e6c-83a0-4e2b7d15ab51@arm.com> (raw) In-Reply-To: <20161010221332.GD44885@linaro.org> On 10/10/16 23:13, Lina Iyer wrote: > On Mon, Oct 10 2016 at 11:13 -0600, Sudeep Holla wrote: [...] >> Either we say this binding is ARM CPU specific or generic, I can't >> understand this mix 'n' match really. You have removed all the >> CPUIdle stuff from this series which is good and makes it simpler, >> but linking it to only "arm,idle-state" make be feel it's not >> generic. OK I will have a look at the RFC as why generic compatible >> was rejected. >> > I will look for the discussion around it as well. A initial look > through didn't get me the thread I was looking for. > Sure [...] >> >> I understand that but it's not that simple which I assume you *do* >> agree. Hence may need bit of an explanation in the binding(not here >> of-course as I mentioned earlier, but in the CPU Idle bindings). >> Please consider DT bindings as any other specification. All I am >> asking is more description in the binding. >> > Any ideas of what description you would like to see? It seemed fairly > explanatory in the idle-states.txt, so I didn't go into depth here. > Various use cases we discussed and what takes precedence,... etc E.g.: if the Renasas example I pointed out had cpu-idle-states and power-domain but no domain-idle-states which is perfectly valid without this bindings. Basically all the important this we have discussed so far. Even the OSC/PCC is worth mentioning so that we are explicitly clear that this binding has no affiliation to those PSCI methods. In short it should be able to answer any question one might get if is completely new to this binding but is aware of old one. [...] >> >> Agreed and sorry if I created any confusion. But this binding doesn't >> clearly state how to build up the hierarchy if the leaf node is not a >> power-domain node and I am just trying have those clarifications in the >> binding. It would be good if those details are *explicitly* mentioned in >> the binding, not this particularly, but in CPU Idle one when you >> introduce the user of that. >> > As we have today, devices have their own way of figuring out their idle > states, they are not represented in DT (CPU being an exception). I understand that, and I assume this binding will provide a way to represent that for devices too if required. No ? Otherwise I see no point in just saying it's generic. -- Regards, Sudeep
WARNING: multiple messages have this Message-ID (diff)
From: sudeep.holla@arm.com (Sudeep Holla) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v2 5/8] dt/bindings: Update binding for PM domain idle states Date: Tue, 11 Oct 2016 12:29:30 +0100 [thread overview] Message-ID: <5a50adda-5c34-2e6c-83a0-4e2b7d15ab51@arm.com> (raw) In-Reply-To: <20161010221332.GD44885@linaro.org> On 10/10/16 23:13, Lina Iyer wrote: > On Mon, Oct 10 2016 at 11:13 -0600, Sudeep Holla wrote: [...] >> Either we say this binding is ARM CPU specific or generic, I can't >> understand this mix 'n' match really. You have removed all the >> CPUIdle stuff from this series which is good and makes it simpler, >> but linking it to only "arm,idle-state" make be feel it's not >> generic. OK I will have a look at the RFC as why generic compatible >> was rejected. >> > I will look for the discussion around it as well. A initial look > through didn't get me the thread I was looking for. > Sure [...] >> >> I understand that but it's not that simple which I assume you *do* >> agree. Hence may need bit of an explanation in the binding(not here >> of-course as I mentioned earlier, but in the CPU Idle bindings). >> Please consider DT bindings as any other specification. All I am >> asking is more description in the binding. >> > Any ideas of what description you would like to see? It seemed fairly > explanatory in the idle-states.txt, so I didn't go into depth here. > Various use cases we discussed and what takes precedence,... etc E.g.: if the Renasas example I pointed out had cpu-idle-states and power-domain but no domain-idle-states which is perfectly valid without this bindings. Basically all the important this we have discussed so far. Even the OSC/PCC is worth mentioning so that we are explicitly clear that this binding has no affiliation to those PSCI methods. In short it should be able to answer any question one might get if is completely new to this binding but is aware of old one. [...] >> >> Agreed and sorry if I created any confusion. But this binding doesn't >> clearly state how to build up the hierarchy if the leaf node is not a >> power-domain node and I am just trying have those clarifications in the >> binding. It would be good if those details are *explicitly* mentioned in >> the binding, not this particularly, but in CPU Idle one when you >> introduce the user of that. >> > As we have today, devices have their own way of figuring out their idle > states, they are not represented in DT (CPU being an exception). I understand that, and I assume this binding will provide a way to represent that for devices too if required. No ? Otherwise I see no point in just saying it's generic. -- Regards, Sudeep
next prev parent reply other threads:[~2016-10-11 11:29 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 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 [this message] 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=5a50adda-5c34-2e6c-83a0-4e2b7d15ab51@arm.com \ --to=sudeep.holla@arm.com \ --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=lina.iyer@linaro.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=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.