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. > .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
