On Mon, Jan 24, 2011 at 3:55 PM, Santosh Shilimkar <santosh.shilimkar@xxxxxx> wrote: > Jean > >> -----Original Message----- >> From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- >> owner@xxxxxxxxxxxxxxx] On Behalf Of jean.pihet@xxxxxxxxxxxxxx >> Sent: Monday, January 24, 2011 7:51 PM >> To: Thomas Renninger; linux-omap@xxxxxxxxxxxxxxx >> Cc: Jean Pihet >> Subject: [PATCH] perf: add OMAP support for the new power events >> >> From: Jean Pihet <j-pihet@xxxxxx> >> >> The patch adds the new power management trace points for >> the OMAP architecture. >> >> The trace points are for: >> - default idle handler. Since the cpuidle framework is >> instrumented in the generic way there is no need to >> add trace points in the OMAP specific cpuidle handler; >> - cpufreq (DVFS), >> - SoC clocks changes (enable, disable, set_rate), >> - change of power domains next power states. >> >> Tested on OMAP3 with suspend/resume, cpuidle, basic DVFS >> > [....] > >> diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach- >> omap2/powerdomain.c >> index eaed0df..e1feb50 100644 >> --- a/arch/arm/mach-omap2/powerdomain.c >> +++ b/arch/arm/mach-omap2/powerdomain.c >> @@ -19,12 +19,15 @@ >> #include <linux/list.h> >> #include <linux/errno.h> >> #include <linux/string.h> >> +#include <trace/events/power.h> >> + >> #include "cm2xxx_3xxx.h" >> #include "prcm44xx.h" >> #include "cm44xx.h" >> #include "prm2xxx_3xxx.h" >> #include "prm44xx.h" >> >> +#include <asm/cpu.h> >> #include <plat/cpu.h> >> #include "powerdomain.h" >> #include "clockdomain.h" >> @@ -406,8 +409,11 @@ int pwrdm_set_next_pwrst(struct powerdomain >> *pwrdm, u8 pwrst) >> pr_debug("powerdomain: setting next powerstate for %s to >> %0x\n", >> pwrdm->name, pwrst); >> >> - if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst) >> + if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst) { >> + trace_power_domain_target(pwrdm->name, pwrst, >> + smp_processor_id()); >> ret = arch_pwrdm->pwrdm_set_next_pwrst(pwrdm, pwrst); >> + } >> >> return ret; >> } > We need to track the actual power domain transitions as well > at hardware level. Agree > Can you please look at "pwrdm_pre_transition()" and > "pwrdm_post_transition()" > This code keep track of it using the next power state > and prev-power state. The current API only has 'trace_power_domain_target' which tracks the desired target state. I think we need an extra tracer 'trace_power_domain_hitstate' so that the trace parser can compare the desired ('target') and actually hit ('hitstate') states. Thanks, Jean > > Regards, > Santosh > -- 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
