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

On Fri, Aug 12 2016 at 06:35 -0600, Brendan Jackman wrote:

quoted

quoted

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

quoted

quoted

CORE_PG + CLUSTER_RET
CORE_PG + CLUSTER_PG

Cheers,
Brendan