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
--
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
