On Sat, Feb 4, 2012 at 5:36 PM, Colin Cross ccross@google.com wrote:
On Sat, Feb 4, 2012 at 2:06 PM, Turquette, Mike mturquette@ti.com wrote:
On Sat, Feb 4, 2012 at 11:02 AM, Colin Cross ccross@google.com wrote:
What's the point of the pre_enter call? This seems very similar to the prepare call that was removed in 3.2. Drivers can already demote
Hi Colin,
I asked Rob to re-introduce the .prepare callback (not .pre_enter).
The short version of why I requested this is so that I can experiment with modifying wake-up latency and theshold values dynamically based on PM QoS constraints. For an OMAP-specific example, I'd like to see our C-states no longer model both MPU and CORE power domains, and instead only model the MPU. Then when entering idle the PM QoS constraints against the CORE power domain's wake-up latency can be considered in the .prepare callback which will affect the C-state parameters as well as program the CORE low power target state.
prepare makes sense to adjust latencies, as long as it is not used for state demotion as well.
Latency adjustment is the plan. State demotion is not.
Rob,
If you cook up another version of this series feel free to drop .pre_enter. It would be nice if you re-introduced .prepare as per our original discussion but if that's a roadblock then you can forget that point too and I'll take a crack at it later.
Regards, Mike
.pre_enter isn't really right for the above case so I'm happy for it to be dropped, but I'll probably re-introduce something like .prepare in the future...
Regards, Mike
the target state in their enter call. The only thing you do between pre_enter and enter is trace and account for the time. Is there some long call you don't want included in the idle time? Some documentation would help, and you need to very clearly define the semantics of when post_enter gets called when pre_enter or enter return errors.
linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel