[PATCH v3 02/15] dt/bindings: Update binding for PM domain idle states

[Brendan Jackman]

On 15/08/16 23:40, Lina Iyer wrote:
> On Mon, Aug 15 2016 at 10:14 -0600, Sudeep Holla wrote:
>>
>>
>> On 15/08/16 17:08, Lina Iyer wrote:
>>> On Fri, Aug 12 2016 at 04:08 -0600, Sudeep Holla wrote:
>>>>
>>>>
>>>> On 11/08/16 22:10, Lina Iyer wrote:
>>>>> On Wed, Aug 10 2016 at 12:09 -0600, Sudeep Holla wrote:
>>>>>>
>>>>
>>>> [...]
>>>>
>>>>>> cluster0
>>>>>>   CLUSTER_RET(Retention)
>>>>>>   CLUSTER_PG(Power Gate)
>>>>>>   core0
>>>>>>       CORE_RET
>>>>>>       CORE_PG
>>>>>>   core1
>>>>>>       CORE_RET
>>>>>>       CORE_PG
>>>>>>
>>>>>> cluster1
>>>>>>   CLUSTER_RET
>>>>>>   CLUSTER_PG
>>>>>>   core0
>>>>>>       CORE_RET
>>>>>>       CORE_PG
>>>>>>   core1
>>>>>>       CORE_RET
>>>>>>       CORE_PG
>>>>>>
>>>>>> Platform Co-ordinate supports the following states and we should be
>>>>>> able to determine that from the binding:
>>>>>>
>>>>>> CORE_RET
>>>>>> CORE_PG
>>>>>> CORE_RET + CLUSTER_RET
>>>>>
>>>>> The problem that we have to sove here is knowing that CORE_RET +
>>>>> CLUSTER_PG (hypothetically) an invalid combination. Kevin and
>>>>> I debated it in the earlier RFC and we dont have a good way to solve
>>>>> this generically for all devices.
>>>>>
>>>>
>>>> Yes, I agree it's complex. But that needs to be solved IMO.
>>>>
>>>> I can think of 2 possible solutions:
>>>>
>>>> 1. Index the states(which people have not liked, but as along as we
>>>>  don't use it in the code as it for any other purpose, it should be
>>>>  fine) and then have each state mentioning what parent state can be
>>>>  entered at this child state(i.e. starting index and all states below
>>>>  it)
>>>>
>>> This is how QCOM solved it downstream.
>>>
>>
>> Yes even ACPI has indices to solve this.
>>
>>>> 2. Something similar to (1) but without index instead phandles.
>>>>
>>>
>>> The problem is when you have non-CPU devices in the device tree and
>>> since they do not have a way to represent states like CPU, we did not
>>> have a clear path to that. Hence we punted that to later. Whatever we
>>> do, we should solve it for a generic PM domain, not just CPU domains.
>>>
>>
>> Yes bindings defined here should be applicable for devices to, but only
>> CPU's will have this hierarchy while the devices need not bother about
>> hierarchy. However the parent power domain can ever the state which is
>> least common denominator of all it's children power domain. That's my
>> understanding. No ?
>>

Are you saying that the parent can enter the shallowest idle state that
all its children are in (I.e if all its children are in "retention" then
it can enter "retention")? I don't know what the reality is on existing
platforms but it doesn't sound like 100% safe assumption to make. Also I
don't think you can necessarily correlate idle states at different
domain levels - i.e. here we've matched up the idea of "retention" at
core level with that of "retention" at cluster level. I may have
misunderstood you there..

> That is correct. But say if all the CPUs choose CORE_RET + CLUSTER_PG,
> which is invalid and the firmware has to ignore it and does CORE_RET +
> CLUSTER_RET instead, then Linux may have an inconsistent view of the
> state selection.
>
Perhaps a better starting point would be to go with the assumption that
a parent PD can only enter any idle state once its children are in their
deepest idle states.

That is, we'd miss out on CORE_RET + CLUSTER_RET but have no invalid ones.

Then a later addition to the bindings as discussed above could enable
the possibility of those combinations to be expressed.
> Thanks,
> Lina
>
>> --
>> Regards,
>> Sudeep
>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.