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

Lina Iyer
2016-08-15T16:08:57Z

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.

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

Thanks,
Lina

>Again these are just thoughts, others may think of some better
>solution(s). Sorry I haven't followed all the previous threads in detail.
>
>--
>Regards,
>Sudeep