On Fri, Aug 27, 2010 at 2:01 AM, Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> wrote: > Jean Pihet <jean.pihet@xxxxxxxxxxxxxx> writes: > >> Hi Kevin, >> >> On Wed, Aug 25, 2010 at 8:22 PM, Kevin Hilman >> <khilman@xxxxxxxxxxxxxxxxxxx> wrote: >>> Hi Jean, >>> >>> Jean Pihet <jean.pihet@xxxxxxxxxxxxxx> writes: >>> >> ... >>> >>>> Add the cpuidle power_start and power_end events. The state >>>> parameter of power_start has the following meaning: >>>> - -1: from the suspend handler (omap3_pm_suspend), >>>> - 1: from the default idle handler (omap3_pm_idle), >>>> - other values are the C-states from the cpuidle handler >>>> (omap3_enter_idle). >>> >>> Are these definitions standard across other arches too? The use of >>> POWER_CSTATE from supend seems less than intuitive. >> Only x86 is using those events, and only for idle (values >= 0). >> I have added -1 to differentiate the suspend from the regular idle but >> it sems that it is not the best option. >> Is a new type of power event more suited, e.g. POWER_SSTATE? If so I >> will have to add it in the event definition header (in >> include/trace/events/power.h) and the patch will be submitted to LKML. > > Yes, I think a new event is probably more appropriate, but should be > discussed on LKML. Indeed. Here is a respin of the patch, on top of the l-o tree. The rest of the changes are discussed on LKML. > > Kevin > Jean --- Add the cpuidle power_start and power_end events. The state parameter of power_start has the following meaning: - 1: from the default idle handler (omap3_pm_idle), - other values are the C-states from the cpuidle handler (omap3_enter_idle). Add the cpufreq power_frequency event, with the state parameter being the target CPU frequency. Cf. http://omappedia.org/wiki/Power_Management_Debug_and_Profiling for more details on PM debug and profiling. Signed-off-by: Jean Pihet <jpihet@xxxxxx> --- arch/arm/mach-omap2/cpuidle34xx.c | 2 ++ arch/arm/mach-omap2/pm34xx.c | 2 ++ arch/arm/plat-omap/cpu-omap.c | 5 ++++- 3 files changed, 8 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 3d3d035..6113bd9 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -24,6 +24,7 @@ #include <linux/sched.h> #include <linux/cpuidle.h> +#include <trace/events/power.h> #include <plat/prcm.h> #include <plat/irqs.h> @@ -130,6 +131,7 @@ static int omap3_enter_idle(struct cpuidle_device *dev, local_irq_disable(); local_fiq_disable(); + trace_power_start(POWER_CSTATE, cx->type, smp_processor_id()); pwrdm_set_next_pwrst(mpu_pd, mpu_state); pwrdm_set_next_pwrst(core_pd, core_state); diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index f25bc3d..04bc758 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -28,6 +28,7 @@ #include <linux/clk.h> #include <linux/delay.h> #include <linux/slab.h> +#include <trace/events/power.h> #include <plat/sram.h> #include <plat/clockdomain.h> @@ -588,6 +589,7 @@ static void omap3_pm_idle(void) if (omap_irq_pending() || need_resched()) goto out; + trace_power_start(POWER_CSTATE, 1, smp_processor_id()); omap_sram_idle(); out: diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c index df08829..cc4e41f 100644 --- a/arch/arm/plat-omap/cpu-omap.c +++ b/arch/arm/plat-omap/cpu-omap.c @@ -25,6 +25,7 @@ #include <linux/err.h> #include <linux/clk.h> #include <linux/io.h> +#include <trace/events/power.h> #include <mach/hardware.h> #include <plat/clock.h> @@ -116,8 +117,10 @@ static int omap_target(struct cpufreq_policy *policy, cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE); #elif defined(CONFIG_ARCH_OMAP3) && !defined(CONFIG_OMAP_PM_NONE) freq = target_freq * 1000; - if (opp_find_freq_ceil(mpu_dev, &freq)) + if (opp_find_freq_ceil(mpu_dev, &freq)) { + trace_power_frequency(POWER_PSTATE, freq, smp_processor_id()); omap_pm_cpu_set_freq(freq); + } #endif return ret; } -- 1.7.1 -- 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
