On Tue, Jan 4, 2011 at 7:03 PM, Nishanth Menon <nm@xxxxxx> wrote: > jean.pihet@xxxxxxxxxxxxxx had written, on 01/04/2011 04:17 AM, the > following: > [..] >> >> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c >> index 0ec8a04..0ee0b0e 100644 >> --- a/arch/arm/mach-omap2/pm34xx.c >> +++ b/arch/arm/mach-omap2/pm34xx.c >> @@ -29,6 +29,7 @@ >> #include <linux/delay.h> >> #include <linux/slab.h> >> #include <linux/console.h> >> +#include <trace/events/power.h> >> #include <plat/sram.h> >> #include <plat/clockdomain.h> >> @@ -506,8 +507,14 @@ static void omap3_pm_idle(void) >> if (omap_irq_pending() || need_resched()) >> goto out; >> + trace_power_start(POWER_CSTATE, 1, smp_processor_id()); >> + trace_cpu_idle(1, smp_processor_id()); >> + >> omap_sram_idle(); >> + trace_power_end(smp_processor_id()); >> + trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id()); > > Dumb question: it just tells me which C state was attempted - not if > actually succeeded in hitting it rt? Does'nt this give us a false data? Yes this tracks the idle requests only. The actual hit state might be different depending on various factors: HW state, enabled clocks, power domains dependencies etc. Debugging the actual PM hit state requires other tools, which could use the trace API. There is definitely more to come on that topic. > > [..] >> >> diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c >> index fc62fb5..7cbb09b 100644 >> --- a/arch/arm/plat-omap/clock.c >> +++ b/arch/arm/plat-omap/clock.c > > (from an offline discussion on a related topic): Would it also be nice to > hook on mach-omap2/clock.c points as well to hook on indirect changes? > [..] > > -- > Regards, > Nishanth Menon > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html