* [PATCH] perf: add OMAP support for the new power events
@ 2011-01-24 14:20 jean.pihet
2011-01-24 14:55 ` Santosh Shilimkar
2011-02-10 21:02 ` Kevin Hilman
0 siblings, 2 replies; 10+ messages in thread
From: jean.pihet @ 2011-01-24 14:20 UTC (permalink / raw)
To: Thomas Renninger, linux-omap; +Cc: Jean Pihet
From: Jean Pihet <j-pihet@ti.com>
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
Signed-off-by: Jean Pihet <j-pihet@ti.com>
---
arch/arm/mach-omap2/clock.c | 8 +++++++-
arch/arm/mach-omap2/pm34xx.c | 7 +++++++
arch/arm/mach-omap2/powerdomain.c | 8 +++++++-
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 2a2f152..72af75d 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -22,7 +22,9 @@
#include <linux/clk.h>
#include <linux/io.h>
#include <linux/bitops.h>
+#include <trace/events/power.h>
+#include <asm/cpu.h>
#include <plat/clock.h>
#include "clockdomain.h"
#include <plat/cpu.h>
@@ -261,6 +263,7 @@ void omap2_clk_disable(struct clk *clk)
pr_debug("clock: %s: disabling in hardware\n", clk->name);
+ trace_clock_disable(clk->name, 0, smp_processor_id());
clk->ops->disable(clk);
if (clk->clkdm)
@@ -312,6 +315,7 @@ int omap2_clk_enable(struct clk *clk)
}
}
+ trace_clock_enable(clk->name, 1, smp_processor_id());
ret = clk->ops->enable(clk);
if (ret) {
WARN(1, "clock: %s: could not enable: %d\n", clk->name, ret);
@@ -349,8 +353,10 @@ int omap2_clk_set_rate(struct clk *clk, unsigned long rate)
pr_debug("clock: set_rate for clock %s to rate %ld\n", clk->name, rate);
/* dpll_ck, core_ck, virt_prcm_set; plus all clksel clocks */
- if (clk->set_rate)
+ if (clk->set_rate) {
+ trace_clock_set_rate(clk->name, rate, smp_processor_id());
ret = clk->set_rate(clk, rate);
+ }
return ret;
}
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 8cbbead..7c5e0ee 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 "clockdomain.h"
@@ -518,8 +519,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());
+
out:
local_fiq_enable();
local_irq_enable();
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;
}
--
1.7.2.3
^ permalink raw reply related [flat|nested] 10+ messages in thread
* RE: [PATCH] perf: add OMAP support for the new power events
2011-01-24 14:20 [PATCH] perf: add OMAP support for the new power events jean.pihet
@ 2011-01-24 14:55 ` Santosh Shilimkar
2011-01-26 9:49 ` Jean Pihet
2011-02-10 21:02 ` Kevin Hilman
1 sibling, 1 reply; 10+ messages in thread
From: Santosh Shilimkar @ 2011-01-24 14:55 UTC (permalink / raw)
To: jean.pihet, Thomas Renninger, linux-omap; +Cc: Jean Pihet-XID
Jean
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of jean.pihet@newoldbits.com
> Sent: Monday, January 24, 2011 7:51 PM
> To: Thomas Renninger; linux-omap@vger.kernel.org
> Cc: Jean Pihet
> Subject: [PATCH] perf: add OMAP support for the new power events
>
> From: Jean Pihet <j-pihet@ti.com>
>
> 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.
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.
Regards,
Santosh
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] perf: add OMAP support for the new power events
2011-01-24 14:55 ` Santosh Shilimkar
@ 2011-01-26 9:49 ` Jean Pihet
2011-01-26 10:06 ` Santosh Shilimkar
0 siblings, 1 reply; 10+ messages in thread
From: Jean Pihet @ 2011-01-26 9:49 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: Thomas Renninger, linux-omap, Jean Pihet-XID
On Mon, Jan 24, 2011 at 3:55 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> Jean
>
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> owner@vger.kernel.org] On Behalf Of jean.pihet@newoldbits.com
>> Sent: Monday, January 24, 2011 7:51 PM
>> To: Thomas Renninger; linux-omap@vger.kernel.org
>> Cc: Jean Pihet
>> Subject: [PATCH] perf: add OMAP support for the new power events
>>
>> From: Jean Pihet <j-pihet@ti.com>
>>
>> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [PATCH] perf: add OMAP support for the new power events
2011-01-26 9:49 ` Jean Pihet
@ 2011-01-26 10:06 ` Santosh Shilimkar
2011-02-07 16:05 ` Jean Pihet
0 siblings, 1 reply; 10+ messages in thread
From: Santosh Shilimkar @ 2011-01-26 10:06 UTC (permalink / raw)
To: Jean Pihet; +Cc: Thomas Renninger, linux-omap, Jean Pihet-XID
> -----Original Message-----
> From: Jean Pihet [mailto:jean.pihet@newoldbits.com]
> Sent: Wednesday, January 26, 2011 3:20 PM
> To: Santosh Shilimkar
> Cc: Thomas Renninger; linux-omap@vger.kernel.org; Jean Pihet-XID
> Subject: Re: [PATCH] perf: add OMAP support for the new power events
>
[...]
> > 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.
>
We use next state and previous state. 'hitstate' doesn't sound
well that's really secondary.
Do you plan to add that additional trace then ?
Regards,
Santosh
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] perf: add OMAP support for the new power events
2011-01-26 10:06 ` Santosh Shilimkar
@ 2011-02-07 16:05 ` Jean Pihet
2011-02-07 16:12 ` Santosh Shilimkar
0 siblings, 1 reply; 10+ messages in thread
From: Jean Pihet @ 2011-02-07 16:05 UTC (permalink / raw)
To: Santosh Shilimkar, Tony Lindgren
Cc: Thomas Renninger, linux-omap, Jean Pihet-XID
Hi Santosh, Tony,
On Wed, Jan 26, 2011 at 11:06 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
>> -----Original Message-----
>> From: Jean Pihet [mailto:jean.pihet@newoldbits.com]
>> Sent: Wednesday, January 26, 2011 3:20 PM
>> To: Santosh Shilimkar
>> Cc: Thomas Renninger; linux-omap@vger.kernel.org; Jean Pihet-XID
>> Subject: Re: [PATCH] perf: add OMAP support for the new power events
>>
> [...]
>
>> > 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.
>>
> We use next state and previous state. 'hitstate' doesn't sound
> well that's really secondary.
>
> Do you plan to add that additional trace then ?
Yes that is idea, although adding new events in the power trace API
has been proved as quite difficult to get accepted. In any case this
will be done separately (iow it is not part of this patch).
Also this patch also supports OMAP4 since the changes are in the
generic PM frameworks. Thanks to the OMAP PM arch guys ;p
Is the patch OK? If so can it be queued in the l-o tree?
>
> Regards,
> Santosh
>
Regards,
Jean
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [PATCH] perf: add OMAP support for the new power events
2011-02-07 16:05 ` Jean Pihet
@ 2011-02-07 16:12 ` Santosh Shilimkar
2011-02-11 14:38 ` Are there CPU sleep residency HW counters in OMAP? Was: " Thomas Renninger
0 siblings, 1 reply; 10+ messages in thread
From: Santosh Shilimkar @ 2011-02-07 16:12 UTC (permalink / raw)
To: Jean Pihet, Tony Lindgren; +Cc: Thomas Renninger, linux-omap, Jean Pihet-XID
Jean,
> -----Original Message-----
> From: Jean Pihet [mailto:jean.pihet@newoldbits.com]
> Sent: Monday, February 07, 2011 9:36 PM
> To: Santosh Shilimkar; Tony Lindgren
> Cc: Thomas Renninger; linux-omap@vger.kernel.org; Jean Pihet-XID
> Subject: Re: [PATCH] perf: add OMAP support for the new power events
>
> Hi Santosh, Tony,
>
> On Wed, Jan 26, 2011 at 11:06 AM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
> >> -----Original Message-----
> >> From: Jean Pihet [mailto:jean.pihet@newoldbits.com]
> >> Sent: Wednesday, January 26, 2011 3:20 PM
> >> To: Santosh Shilimkar
> >> Cc: Thomas Renninger; linux-omap@vger.kernel.org; Jean Pihet-XID
> >> Subject: Re: [PATCH] perf: add OMAP support for the new power
> events
> >>
> > [...]
> >
> >> > 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.
> >>
> > We use next state and previous state. 'hitstate' doesn't sound
> > well that's really secondary.
> >
> > Do you plan to add that additional trace then ?
> Yes that is idea, although adding new events in the power trace API
> has been proved as quite difficult to get accepted. In any case this
> will be done separately (iow it is not part of this patch).
>
> Also this patch also supports OMAP4 since the changes are in the
> generic PM frameworks. Thanks to the OMAP PM arch guys ;p
>
> Is the patch OK? If so can it be queued in the l-o tree?
>
I just looked at from the current need of DEBUG counters
and commented what needs to be supported.
Am ok with the patch, but that means we still need to keep using
and supporting PM debug counters till we support the additional
trace events.
May be Kevin/Paul can take a call on this.
Regards,
Santosh
^ permalink raw reply [flat|nested] 10+ messages in thread
* Are there CPU sleep residency HW counters in OMAP? Was: Re: [PATCH] perf: add OMAP support for the new power events
2011-02-07 16:12 ` Santosh Shilimkar
@ 2011-02-11 14:38 ` Thomas Renninger
2011-02-11 15:07 ` Santosh Shilimkar
0 siblings, 1 reply; 10+ messages in thread
From: Thomas Renninger @ 2011-02-11 14:38 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: Tony Lindgren, linux-omap, Jean Pihet-XID
Hi,
I use this thread as I expect people following it, is exactly
the audience I am looking out for.
I am currently implementing a generic framework for CPU idle
state accounting.
X86 CPUs can do quite some magic behind the OS and might enter
deeper sleep states or might not enter them, even the OS requested
(not) to do so.
Intel and AMD provide, depending on the CPU family, different HW
counters to read out which state the HW really entered.
One can also use some counters which are not explicitly made for
that. For example in X86 there is the mperf counter ticking at
max frequency like TSC, but unlike the TSC it stops when entering
any sleep state. This for example will also be one of the counters
to account C0 vs Cx time the HW really resided in.
The stuff is intended for the cpupowerutils (new branch on the
cpufrequtils tree) package. It should replace the turbostat tool
which is doing this for some Intel x86 cpus only and recently got
merged into the kernel:
linux-2.6/tools/power/x86/turbostat/
I still have to make sure to compile out X86 specific stuff
(accessing MSRs, cpuid..) for other archs and with a next, cleaned up
patch series the accounting statistics from
/sys/devices/system/cpu/cpu*/cpuidle/* should work on other archs as
well.
Anyway, if there are facilities to read out sleep state residency from
HW for omap based cpus and you like to have a tool showing them,
it would be great if someone likes to help with the implementation.
The framework will be there already, I would just need some help with
a omap_monitor.c file filling up some callback functions and there could
be one tool with the same format for all archs showing sleep states...
Thanks,
Thomas
On Monday, February 07, 2011 05:12:18 PM Santosh Shilimkar wrote:
> Jean,
> > -----Original Message-----
> > From: Jean Pihet [mailto:jean.pihet@newoldbits.com]
> > Sent: Monday, February 07, 2011 9:36 PM
> > To: Santosh Shilimkar; Tony Lindgren
> > Cc: Thomas Renninger; linux-omap@vger.kernel.org; Jean Pihet-XID
> > Subject: Re: [PATCH] perf: add OMAP support for the new power events
> >
> > Hi Santosh, Tony,
> >
> > On Wed, Jan 26, 2011 at 11:06 AM, Santosh Shilimkar
> > <santosh.shilimkar@ti.com> wrote:
> > >> -----Original Message-----
> > >> From: Jean Pihet [mailto:jean.pihet@newoldbits.com]
> > >> Sent: Wednesday, January 26, 2011 3:20 PM
> > >> To: Santosh Shilimkar
> > >> Cc: Thomas Renninger; linux-omap@vger.kernel.org; Jean Pihet-XID
> > >> Subject: Re: [PATCH] perf: add OMAP support for the new power
> > events
> > >>
> > > [...]
> > >
> > >> > 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.
> > >>
> > > We use next state and previous state. 'hitstate' doesn't sound
> > > well that's really secondary.
> > >
> > > Do you plan to add that additional trace then ?
> > Yes that is idea, although adding new events in the power trace API
> > has been proved as quite difficult to get accepted. In any case this
> > will be done separately (iow it is not part of this patch).
> >
> > Also this patch also supports OMAP4 since the changes are in the
> > generic PM frameworks. Thanks to the OMAP PM arch guys ;p
> >
> > Is the patch OK? If so can it be queued in the l-o tree?
> >
> I just looked at from the current need of DEBUG counters
> and commented what needs to be supported.
>
> Am ok with the patch, but that means we still need to keep using
> and supporting PM debug counters till we support the additional
> trace events.
>
> May be Kevin/Paul can take a call on this.
>
> Regards,
> Santosh
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Are there CPU sleep residency HW counters in OMAP? Was: Re: [PATCH] perf: add OMAP support for the new power events
2011-02-11 14:38 ` Are there CPU sleep residency HW counters in OMAP? Was: " Thomas Renninger
@ 2011-02-11 15:07 ` Santosh Shilimkar
0 siblings, 0 replies; 10+ messages in thread
From: Santosh Shilimkar @ 2011-02-11 15:07 UTC (permalink / raw)
To: Thomas Renninger, Kevin Hilman, Paul Walmsley
Cc: Tony Lindgren, linux-omap, Jean Pihet-XID
(+ Kevin, Paul)
> -----Original Message-----
> From: Thomas Renninger [mailto:trenn@suse.de]
> Sent: Friday, February 11, 2011 8:09 PM
> To: Santosh Shilimkar
> Cc: Tony Lindgren; linux-omap@vger.kernel.org; Jean Pihet-XID
> Subject: Are there CPU sleep residency HW counters in OMAP? Was: Re:
> [PATCH] perf: add OMAP support for the new power events
>
> Hi,
>
> I use this thread as I expect people following it, is exactly
> the audience I am looking out for.
>
> I am currently implementing a generic framework for CPU idle
> state accounting.
>
> X86 CPUs can do quite some magic behind the OS and might enter
> deeper sleep states or might not enter them, even the OS requested
> (not) to do so.
>
> Intel and AMD provide, depending on the CPU family, different HW
> counters to read out which state the HW really entered.
>
> One can also use some counters which are not explicitly made for
> that. For example in X86 there is the mperf counter ticking at
> max frequency like TSC, but unlike the TSC it stops when entering
> any sleep state. This for example will also be one of the counters
> to account C0 vs Cx time the HW really resided in.
>
I assume HW means CPU here. The current OMAP's doesn't have
hardware counter registers to measure CPU residency time in
deeper sleep states. Intrusive instrumentation using always
running counter is possible buts no good. Hence Jean is
trying to have common trace framework do some of these.
> The stuff is intended for the cpupowerutils (new branch on the
> cpufrequtils tree) package. It should replace the turbostat tool
> which is doing this for some Intel x86 cpus only and recently got
> merged into the kernel:
> linux-2.6/tools/power/x86/turbostat/
>
> I still have to make sure to compile out X86 specific stuff
> (accessing MSRs, cpuid..) for other archs and with a next, cleaned
> up
> patch series the accounting statistics from
> /sys/devices/system/cpu/cpu*/cpuidle/* should work on other archs as
> well.
>
> Anyway, if there are facilities to read out sleep state residency
> from
> HW for omap based cpus and you like to have a tool showing them,
> it would be great if someone likes to help with the implementation.
>
> The framework will be there already, I would just need some help
> with
> a omap_monitor.c file filling up some callback functions and there
> could
> be one tool with the same format for all archs showing sleep
> states...
>
Various IPs in OMAP are grouped in different Powerdomains. The
Powerdomain states targeted and reached can be read from the
hardware registers and that's what we use more often. Currently
some debug counters can show these stats.
For e.g
OMAP CPU supports below power domains.
1. CPU PD ON/INACTIVE
2. CPU PD RETENTION (2 levels)
3. CPU PD OFF.
C-states can attempt one of these states based available sleep
time and up down latencies. Whether attempted target CPU PD
states was reached or not can be read using hardware registers.
But then we still can't read the exact CPU residency time in
a particular sleep state.
Hope this gives some idea about what's supported by OMAP
hardware for cpuidle residency measurements.
I let Kevin/Pual comment more in case I have missed some
information.
Regards,
Santosh
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] perf: add OMAP support for the new power events
2011-01-24 14:20 [PATCH] perf: add OMAP support for the new power events jean.pihet
2011-01-24 14:55 ` Santosh Shilimkar
@ 2011-02-10 21:02 ` Kevin Hilman
2011-02-18 18:14 ` Jean Pihet
1 sibling, 1 reply; 10+ messages in thread
From: Kevin Hilman @ 2011-02-10 21:02 UTC (permalink / raw)
To: jean.pihet; +Cc: Thomas Renninger, linux-omap, Jean Pihet
jean.pihet@newoldbits.com writes:
> From: Jean Pihet <j-pihet@ti.com>
>
> 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
>
> Signed-off-by: Jean Pihet <j-pihet@ti.com>
Looks good to me. Please post one more time with linux-arm-kernel in Cc.
After that, unless there are objections, I'll queue for 2.6.39.
Kevin
> ---
> arch/arm/mach-omap2/clock.c | 8 +++++++-
> arch/arm/mach-omap2/pm34xx.c | 7 +++++++
> arch/arm/mach-omap2/powerdomain.c | 8 +++++++-
> 3 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
> index 2a2f152..72af75d 100644
> --- a/arch/arm/mach-omap2/clock.c
> +++ b/arch/arm/mach-omap2/clock.c
> @@ -22,7 +22,9 @@
> #include <linux/clk.h>
> #include <linux/io.h>
> #include <linux/bitops.h>
> +#include <trace/events/power.h>
>
> +#include <asm/cpu.h>
> #include <plat/clock.h>
> #include "clockdomain.h"
> #include <plat/cpu.h>
> @@ -261,6 +263,7 @@ void omap2_clk_disable(struct clk *clk)
>
> pr_debug("clock: %s: disabling in hardware\n", clk->name);
>
> + trace_clock_disable(clk->name, 0, smp_processor_id());
> clk->ops->disable(clk);
>
> if (clk->clkdm)
> @@ -312,6 +315,7 @@ int omap2_clk_enable(struct clk *clk)
> }
> }
>
> + trace_clock_enable(clk->name, 1, smp_processor_id());
> ret = clk->ops->enable(clk);
> if (ret) {
> WARN(1, "clock: %s: could not enable: %d\n", clk->name, ret);
> @@ -349,8 +353,10 @@ int omap2_clk_set_rate(struct clk *clk, unsigned long rate)
> pr_debug("clock: set_rate for clock %s to rate %ld\n", clk->name, rate);
>
> /* dpll_ck, core_ck, virt_prcm_set; plus all clksel clocks */
> - if (clk->set_rate)
> + if (clk->set_rate) {
> + trace_clock_set_rate(clk->name, rate, smp_processor_id());
> ret = clk->set_rate(clk, rate);
> + }
>
> return ret;
> }
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 8cbbead..7c5e0ee 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 "clockdomain.h"
> @@ -518,8 +519,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());
> +
> out:
> local_fiq_enable();
> local_irq_enable();
> 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;
> }
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] perf: add OMAP support for the new power events
2011-02-10 21:02 ` Kevin Hilman
@ 2011-02-18 18:14 ` Jean Pihet
0 siblings, 0 replies; 10+ messages in thread
From: Jean Pihet @ 2011-02-18 18:14 UTC (permalink / raw)
To: Kevin Hilman; +Cc: Thomas Renninger, linux-omap, Jean Pihet
On Thu, Feb 10, 2011 at 10:02 PM, Kevin Hilman <khilman@ti.com> wrote:
> jean.pihet@newoldbits.com writes:
>
>> From: Jean Pihet <j-pihet@ti.com>
>>
>> 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
>>
>> Signed-off-by: Jean Pihet <j-pihet@ti.com>
>
> Looks good to me. Please post one more time with linux-arm-kernel in Cc.
> After that, unless there are objections, I'll queue for 2.6.39.
Ok thanks for reviewing the patch.
I sent the updated patch. The change is an extra trace point in the
case a power domain did not hit the desired target state. This allows
the parsing/GUI tools to trace the desired and actually hit states.
Regards,
Jean
>
> Kevin
>
>> ---
>> arch/arm/mach-omap2/clock.c | 8 +++++++-
>> arch/arm/mach-omap2/pm34xx.c | 7 +++++++
>> arch/arm/mach-omap2/powerdomain.c | 8 +++++++-
>> 3 files changed, 21 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
>> index 2a2f152..72af75d 100644
>> --- a/arch/arm/mach-omap2/clock.c
>> +++ b/arch/arm/mach-omap2/clock.c
>> @@ -22,7 +22,9 @@
>> #include <linux/clk.h>
>> #include <linux/io.h>
>> #include <linux/bitops.h>
>> +#include <trace/events/power.h>
>>
>> +#include <asm/cpu.h>
>> #include <plat/clock.h>
>> #include "clockdomain.h"
>> #include <plat/cpu.h>
>> @@ -261,6 +263,7 @@ void omap2_clk_disable(struct clk *clk)
>>
>> pr_debug("clock: %s: disabling in hardware\n", clk->name);
>>
>> + trace_clock_disable(clk->name, 0, smp_processor_id());
>> clk->ops->disable(clk);
>>
>> if (clk->clkdm)
>> @@ -312,6 +315,7 @@ int omap2_clk_enable(struct clk *clk)
>> }
>> }
>>
>> + trace_clock_enable(clk->name, 1, smp_processor_id());
>> ret = clk->ops->enable(clk);
>> if (ret) {
>> WARN(1, "clock: %s: could not enable: %d\n", clk->name, ret);
>> @@ -349,8 +353,10 @@ int omap2_clk_set_rate(struct clk *clk, unsigned long rate)
>> pr_debug("clock: set_rate for clock %s to rate %ld\n", clk->name, rate);
>>
>> /* dpll_ck, core_ck, virt_prcm_set; plus all clksel clocks */
>> - if (clk->set_rate)
>> + if (clk->set_rate) {
>> + trace_clock_set_rate(clk->name, rate, smp_processor_id());
>> ret = clk->set_rate(clk, rate);
>> + }
>>
>> return ret;
>> }
>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>> index 8cbbead..7c5e0ee 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 "clockdomain.h"
>> @@ -518,8 +519,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());
>> +
>> out:
>> local_fiq_enable();
>> local_irq_enable();
>> 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;
>> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-02-18 18:14 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-24 14:20 [PATCH] perf: add OMAP support for the new power events jean.pihet
2011-01-24 14:55 ` Santosh Shilimkar
2011-01-26 9:49 ` Jean Pihet
2011-01-26 10:06 ` Santosh Shilimkar
2011-02-07 16:05 ` Jean Pihet
2011-02-07 16:12 ` Santosh Shilimkar
2011-02-11 14:38 ` Are there CPU sleep residency HW counters in OMAP? Was: " Thomas Renninger
2011-02-11 15:07 ` Santosh Shilimkar
2011-02-10 21:02 ` Kevin Hilman
2011-02-18 18:14 ` Jean Pihet
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.