On Fri, Aug 12 2016 at 06:35 -0600, Brendan Jackman wrote:
>In general whatever binding we come up must not just address OS
>coordinated mode. Also I was thinking to have better coverage in
>the description by having a bit more complex system like:
>
>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.
This is interesting. I had been working on the assumption that a parent
power domain cannot enter any idle state until its children were all in
their deepest idle state. I now realise that it's easy to imagine
platforms where this isn't the case.
However, I don't understand how your current bindings solve this issue
and why using domain-power-states for all states (i.e. ignoring
cpu-idle-states and putting CPU idle states in the domain-idle-states of
a per-CPU power domain - I believe this is what Sudeep is suggesting)
makes it any more difficult.
You are right, my current bindings don't solve it. I imagined one would
solve it by writing their own CPU PM Domain governor. In the context of
platform coordinated, we dont have a choice in Linux. May be the
firmware can assert that intelligence in not choosing those states. So,
we may have states added to cpuidle that are invalid and never get
chosen by the firmware. I am not sure, but may be that is acceptable.
Could you link to this previous discussion you mentioned? I'm having
trouble finding it (R.I.P Gmane).
Sigh. So hard to search. Let me see where it is, if it in mail or IRC
communication.
Thanks,
Lina
>CORE_PG + CLUSTER_RET
>CORE_PG + CLUSTER_PG
>
Cheers,
Brendan
--
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
