On Thu, Jun 23, 2016 at 12:04:51PM -0600, Lina Iyer wrote: > Hi Mark, > > On Thu, Jun 23 2016 at 11:35 -0600, Mark Rutland wrote: > >Hi, > > > >On Wed, Jun 22, 2016 at 01:36:37PM -0600, Lina Iyer wrote: > >>From: Axel Haslam <ahaslam+renesas@xxxxxxxxxxxx> > >> > >>Update DT bindings to describe idle states of PM domains. > >> > >>Cc: <devicetree@xxxxxxxxxxxxxxx> > >>Signed-off-by: Marc Titinger <mtitinger+renesas@xxxxxxxxxxxx> > >>Signed-off-by: Lina Iyer <lina.iyer@xxxxxxxxxx> > >>[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@xxxxxxxxxx> > >>[Ulf: Moved around code to make it compile properly, rebased on top of multiple state support] > >>--- > >> .../devicetree/bindings/power/power_domain.txt | 70 ++++++++++++++++++++++ > >> 1 file changed, 70 insertions(+) > >> > >>diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt > >>index 025b5e7..41e8dda 100644 > >>--- a/Documentation/devicetree/bindings/power/power_domain.txt > >>+++ b/Documentation/devicetree/bindings/power/power_domain.txt > >>@@ -29,6 +29,43 @@ Optional properties: > >> specified by this binding. More details about power domain specifier are > >> available in the next section. > >> > >>+- power-states : A phandle of an idle-state that shall be soaked into a > >>+ generic domain power state. > > > >It's somewhat unfortunate that this gives us two possible locations for > >idle state lists (under the /cpus node and in a pm-domains node), > >especially as it's not clear what would happen were a DT to have both. > > > >I would prefer that we extend the existing bindings such that states can > >refer to the power domains which they affect. > > > I agree. The CPU idle states have become defined to be specific to CPUs. > PM Domain idle states are generic for any type of domain. I am hoping at > some point, we could converge and use the same idle state, but that > would mean changing the CPU idle states to make it generic. Outside of CPU idling, I don't fully understand how this will be used, so it's not clear to me what would need to be made generic. Apologies for my ignorance there. > At some point, during my development, I did use the arm,idle-state for > domains as well, but the binding definitions were too restrictive for > a generic PM domain. > > I would be willing to make the change to CPU idle states to make it > generic and then we could just reference domain and CPU idle states > using the same bindings. Are we okay with that, specifically, > arm,psci-suspend-param? This binding is very restrictive in its > description. What we pass to the platform driver upon choosing a domain > state is very platform specific and therefore has to be generic in its > description. I was suggesting that for PSCI we should consistently us arm,psci-suspend-param, not that this should be used for all power domain state data. I imagine that mechanisms for powering down power domains will have varied requirements on data they require (and may require more than can be encoded in a u32), and I don't think it's best to try to force a single representation in the DT for that. It would be better to allow them to define the properties which they require. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
