On Sat, Feb 4, 2012 at 5:36 PM, Colin Cross <ccross@xxxxxxxxxx> wrote: > On Sat, Feb 4, 2012 at 2:06 PM, Turquette, Mike <mturquette@xxxxxx> wrote: >> On Sat, Feb 4, 2012 at 11:02 AM, Colin Cross <ccross@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx >>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
