[PATCH v5 02/16] dt/bindings: Update binding for PM domain idle states

[brendan.jackman@arm.com (Brendan Jackman)]

On Mon, Sep 12 2016 at 18:09, Sudeep Holla wrote:
> On 12/09/16 17:16, Lina Iyer wrote:
>> On Mon, Sep 12 2016 at 09:19 -0600, Brendan Jackman wrote:
>>>
>>> Hi Lina,
>>>
>>> Sorry for the delay here, Sudeep and I were both been on holiday last
>>> week.
>>>
>>> On Fri, Sep 02 2016 at 21:16, Lina Iyer wrote:
>>>> On Fri, Sep 02 2016 at 07:21 -0700, Sudeep Holla wrote:
>>> [...]
>>>>> This version is *not very descriptive*. Also the discussion we had
>>>>> on v3
>>>>> version has not yet concluded IMO. So can I take that we agreed on what
>>>>> was proposed there or not ?
>>>>>
>>>> Sorry, this example is not very descriptive. Pls. check the 8916 dtsi
>>>> for the new changes in the following patches. Let me know if that makes
>>>> sense.
>
> Please add all possible use-cases in the bindings. Though one can refer
> the usage examples, it might not cover all usage descriptions. It helps
> preventing people from defining their own when they don't see examples.
> Again DT bindings are like specifications, it should be descriptive
> especially this kind of generic ones.
>
>>>
>>> The not-yet-concluded discussion Sudeep is referring to is at [1].
>>>
>>> In that thread we initially proposed the idea of, instead of splitting
>>> state phandles between cpu-idle-states and domain-idle-states, putting
>>> CPUs in their own domains and using domain-idle-states for _all_
>>> phandles, deprecating cpu-idle-states. I've brought this up in other
>>> threads [2] but discussion keeps petering out, and neither this example
>>> nor the 8916 dtsi in this patch series reflect the idea.
>>>
>> Brendan, while your idea is good and will work for CPUs, I do not expect
>> other domains and possibly CPU domains on some architectures to follow
>> this model. There is nothing that prevents you from doing this today,

As I understand it your opposition to this approach is this:

There may be devices/CPUs which have idle states which do not constitute
"power off". If we put those  devices in their own power domain for the
purpose of putting their (non-power-off) idle state phandles in
domain-idle-states, we are "lying" because no true power domain exists
there.

Am I correct that that's your opposition?

If so, it seems we essentially disagree on the definition of a power
domain, i.e. you define it as a set of devices that are powered on/off
together while I define it as a set of devices whose power states
(including idle states, not just on/off) are tied together. I said
something similar on another thread [1] which died out.

Do you agree that this is basically where we disagree, or am I missing
something else?

[2] http://www.spinics.net/lists/devicetree/msg141050.html

>> you can specify domains around CPUs in your devicetree and CPU PM will
>> handle the hierarchy. I don't think its fair to force it on all SoCs
>> using CPU domains.
>
> I disagree. We are defining DT bindings here and it *should* be same for
> all the SoC unless there is a compelling reason not to. I am fine if
> those reasons are stated and agreed.
>
>> This patchset does not restrict you from organizing
>> the idle states the way you want it. This revision of the series, clubs
>> CPU and domain idle states under idle-states umbrella. So part of your
>> requirement is also satisfied.
>>
>
> I will look at the DTS changes in the series. But we *must* have more
> description with more examples in the binding document.
>
>> You can follow up the series with your new additions, I don't see a
>> conflict with this change.
>>
>
> If we just need additions, then it should be fine.