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

Lina Iyer lina.iyer at linaro.org
Mon Aug 15 09:08:57 PDT 2016


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



More information about the linux-arm-kernel mailing list