Sudeep Holla <sudeep.holla@xxxxxxx> writes:
[...]
> 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
Also, remember that a power domain may contain more than just CPUs, so
this will also need to handle things like:
device0..N
DEV_CLK_GATE
DEV_RET
DEV_PG
So, as (I think) Lina was trying to say, including CPU idle states
inside domain idles states doesn't really scale well because it would
also imply domain states would also include device idle states.
IMO, the device-specific states belong in the device nodes, and that
includes CPUs.
It's up to the domain (genpd) governor to look at *all* devices in the
domain, check their state and make a domain-wide decision.
The tricky part remains, IMO, the mapping between device/CPU states and
allowable domain states.
As was suggested earlier, a good potential starting point would be that
all devices/CPUs would need to be in their deepest state before the
domain would make any decisions. While that leaves soem power savings
on the table, it maps well to how genpd works today with only on/off
states and could be extended with more complicated governors down the
road.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
