Re: oprofile and ARM A9 hardware counter
On Sat, May 12, 2012 at 12:51:00AM +0100, Jon Hunter wrote: On 05/11/2012 11:38 AM, Will Deacon wrote: Excellent, that works for me. Once we've worked out the problem with my .config you can have my tested-by. Great! I have been looking at your .config, but I have not been able to figure out the problem so far. Do you recall what your config is based upon? I seems quite different to mine and the omap2plus_defconfig has not changed much in the last few kernel releases. Hmm, I'm honestly not sure -- it was just lying around in my home directory. Given that I know very little about OMAP, I would suspect that it's either based on the defconfig or I inherited a working kernel image from somebody else and used /proc/config.gz to build my own. Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Thu, May 10, 2012 at 07:55:01PM +0100, Jon Hunter wrote: Hi Will, Hi Jon, For my testing I have just been reading the PM_EMU_PWRSTST register which shows the power state of the EMU power domain. It should read 3 when the power domain is ON and 0 when it is off. I did something like the following (dumping all EMU clock and power domain registers). I figured I may as well take perf for a spin and see how I got on. The good news is that the hwmod bits all seem to work as before and the correct IRQs are requested: root@florentine-pogen:~# cat /proc/interrupts CPU0 CPU1 29: 44527 17916 GIC twd 33: 0 0 GIC arm-pmu 34: 0 0 GIC arm-pmu But, unfortunately, as you can see from the above, I just can't persuade them to fire. The PMU counters do tick, but they happily increment through zero without us realising. I retested with my perf/omap4 branch to make sure my board is ok, and the irqs do fire there. Any ideas? Cheers, Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Will On 05/11/2012 07:25 AM, Will Deacon wrote: On Thu, May 10, 2012 at 07:55:01PM +0100, Jon Hunter wrote: Hi Will, Hi Jon, For my testing I have just been reading the PM_EMU_PWRSTST register which shows the power state of the EMU power domain. It should read 3 when the power domain is ON and 0 when it is off. I did something like the following (dumping all EMU clock and power domain registers). I figured I may as well take perf for a spin and see how I got on. The good news is that the hwmod bits all seem to work as before and the correct IRQs are requested: root@florentine-pogen:~# cat /proc/interrupts CPU0 CPU1 29: 44527 17916 GIC twd 33: 0 0 GIC arm-pmu 34: 0 0 GIC arm-pmu But, unfortunately, as you can see from the above, I just can't persuade them to fire. The PMU counters do tick, but they happily increment through zero without us realising. I retested with my perf/omap4 branch to make sure my board is ok, and the irqs do fire there. Any ideas? Do you disable OMAP2/3 support in the kernel config, so that CPU_HAS_PMU is enabled? Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Fri, May 11, 2012 at 02:47:17PM +0100, Jon Hunter wrote: On 05/11/2012 07:25 AM, Will Deacon wrote: I figured I may as well take perf for a spin and see how I got on. The good news is that the hwmod bits all seem to work as before and the correct IRQs are requested: root@florentine-pogen:~# cat /proc/interrupts CPU0 CPU1 29: 44527 17916 GIC twd 33: 0 0 GIC arm-pmu 34: 0 0 GIC arm-pmu But, unfortunately, as you can see from the above, I just can't persuade them to fire. The PMU counters do tick, but they happily increment through zero without us realising. I retested with my perf/omap4 branch to make sure my board is ok, and the irqs do fire there. Any ideas? Do you disable OMAP2/3 support in the kernel config, so that CPU_HAS_PMU is enabled? I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way. Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Will, On 05/11/2012 08:49 AM, Will Deacon wrote: On Fri, May 11, 2012 at 02:47:17PM +0100, Jon Hunter wrote: On 05/11/2012 07:25 AM, Will Deacon wrote: I figured I may as well take perf for a spin and see how I got on. The good news is that the hwmod bits all seem to work as before and the correct IRQs are requested: root@florentine-pogen:~# cat /proc/interrupts CPU0 CPU1 29: 44527 17916 GIC twd 33: 0 0 GIC arm-pmu 34: 0 0 GIC arm-pmu But, unfortunately, as you can see from the above, I just can't persuade them to fire. The PMU counters do tick, but they happily increment through zero without us realising. I retested with my perf/omap4 branch to make sure my board is ok, and the irqs do fire there. Any ideas? Do you disable OMAP2/3 support in the kernel config, so that CPU_HAS_PMU is enabled? I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way. I tried the same (make omap2plus_defconfig and enabled the above option), and I do see the interrupts firing on both 4430 and 4460... / # cat /proc/interrupts CPU0 CPU1 29: 1023404 GIC twd 33:401 0 GIC arm-pmu 34: 0441 GIC arm-pmu What is your kernel commit ID that you applied the patches on top of? What board are you using? Blaze, panda, etc, and is it 4430 or 4460? Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Fri, May 11, 2012 at 03:52:59PM +0100, Jon Hunter wrote: Hi Will, Hello, On 05/11/2012 08:49 AM, Will Deacon wrote: I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way. I tried the same (make omap2plus_defconfig and enabled the above option), and I do see the interrupts firing on both 4430 and 4460... / # cat /proc/interrupts CPU0 CPU1 29: 1023404 GIC twd 33:401 0 GIC arm-pmu 34: 0441 GIC arm-pmu Well, at least it's working for somebody! What is your kernel commit ID that you applied the patches on top of? 7cf543bc (Linux-omap rebuilt: Updated to -rc6, merged in pending branches, please test). Is there something else I need too? What board are you using? Blaze, panda, etc, and is it 4430 or 4460? Ye olde Panda 4430. It does work with my perf/omap4 branch though using the same .config (I can mail it to you separately if you want). Cheers, Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Will, On 05/11/2012 10:02 AM, Will Deacon wrote: On Fri, May 11, 2012 at 03:52:59PM +0100, Jon Hunter wrote: Hi Will, Hello, On 05/11/2012 08:49 AM, Will Deacon wrote: I enabled OMAP3 debug peripherals, so I selected CPU_HAS_PMU that way. I tried the same (make omap2plus_defconfig and enabled the above option), and I do see the interrupts firing on both 4430 and 4460... / # cat /proc/interrupts CPU0 CPU1 29: 1023404 GIC twd 33:401 0 GIC arm-pmu 34: 0441 GIC arm-pmu Well, at least it's working for somebody! What is your kernel commit ID that you applied the patches on top of? 7cf543bc (Linux-omap rebuilt: Updated to -rc6, merged in pending branches, please test). Is there something else I need too? Ok, thanks. I was based upon Tony's -rc5. However, I rebased to the same as you and it is still working for me Can you send me your .config? At the same time, maybe just try make omap2plus_defconfig and enable the OMAP3 debug devices config. That's all I am doing. What board are you using? Blaze, panda, etc, and is it 4430 or 4460? Ye olde Panda 4430. It does work with my perf/omap4 branch though using the same .config (I can mail it to you separately if you want). Ok, should be fine. The kernel should print the ES version on start-up ... [0.00] OMAP4430 ES2.2 What does yours show? Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Fri, May 11, 2012 at 05:31:47PM +0100, Jon Hunter wrote: Can you send me your .config? Sent off-list. At the same time, maybe just try make omap2plus_defconfig and enable the OMAP3 debug devices config. That's all I am doing. Excellent, that works for me. Once we've worked out the problem with my .config you can have my tested-by. Cheers, Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Will, On 05/11/2012 11:38 AM, Will Deacon wrote: On Fri, May 11, 2012 at 05:31:47PM +0100, Jon Hunter wrote: Can you send me your .config? Sent off-list. At the same time, maybe just try make omap2plus_defconfig and enable the OMAP3 debug devices config. That's all I am doing. Excellent, that works for me. Once we've worked out the problem with my .config you can have my tested-by. Great! I have been looking at your .config, but I have not been able to figure out the problem so far. Do you recall what your config is based upon? I seems quite different to mine and the omap2plus_defconfig has not changed much in the last few kernel releases. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Benoit,
On Wednesday 09 May 2012 04:28 PM, Cousson, Benoit wrote:
Hi Kevin and Jon,
On 5/8/2012 11:22 PM, Kevin Hilman wrote:
Jon Hunterjon-hun...@ti.com writes:
Hi Benoit,
On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
[...]
P.S. Please note there is also already a different fix in mainline for
the EMU clkdm data from Paul which adds the force wakeup flag and
removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
because the hardware is capable.)
Hmmm ... yes saw this, and you will have to excuse me as I don't fully
follow the logic here. In fact, I am thinking we want the opposite ;-)
From looking, into this it seems to me that when PMU is running we want
the EMU clock domain in software-wakeup state and when PMU is not
running we want in the hardware auto state.
So far, I'm with you.
By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
domain it is put right back into the HW_AUTO state
This is only because it was in the HWSUP state when _enable was called.
If clkdm_deny_idle() is used, that behavior will change.
and hence PMU is
not working (see _enable() function in
arch/arm/mach-omap2/omap_hwmod.c)
So really what I think we want is to remove the ENABLE_AUTO flag to keep
the clock domain in software wake-up and use the DISABLE_AUTO flag to
put the clock domain back in HW_AUTO (note this requires a patch to
perform this 2nd part).
Well, Paul will have to comment here for the final word, but IIUC, the
hwmod flags are supposed to indicate only what the HW is capable of. If
we want to change the runtime behavior, we nee to use (or add) APIs to
change the beahvior. In this case, clkdm_allow_idle(),
clkdm_deny_idle() are probably what is needed here.
Yes, indeed, we should not hack the flags to fix that kind of issue. The
flags describe what the HW is capable of, and the EMU CD can support
HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
only valid next power state is OFF, meaning that no retention mode is
supported. So any transition to idle will go to OFF and lead to a reset
upon wakeup.
No hacking intended here, just getting the flags correct ;-)
So let me start from the beginning ...
1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
SW_WKUP.
2. When the EMU CD is active (due to something like PMU), we want to
keep the CD in the SW_WKUP state, otherwise we can automatically
transition to idle and reset the IP (at least for omap4430).
3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
state because SW_SLEEP is NOT supported.
In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
set then the omap_pm_clkdms_setup() function will place the CD into
HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
hwmod _enable() is called it is in the HW_AUTO state and so it is
allowed to idle. This is not what we want. Do you agree?
If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
then I do not have the above problem.
To be honest, with you the more I look and test the code, the more
confused I am by the definition of the CLKDM_CAN_HWSUP ...
#define CLKDM_CAN_HWSUP (CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
When I look at where these flags are used, I see that
CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
Are the above the correct definitions?
Not quite.
These flags describe the capabilities as defined in CLKTRCTRL field of
the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)
Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
it's described as The automatic hardware-supervised mode is disabled
Yeah, in fact this is the source of the current confusion for my point of
view.
We chat about that with Paul some time back.
EMU CD does support HW_AUTO and SW_WKUP, so it means that if you want to
disable the AUTO mode you can use the SW_WKUP.
Assuming that CLKDM_CAN_DISABLE_AUTO is equivalent to NO_SLEEP is thus not
correct. In fact any state != HW_AUTO should be considered a non-automatic
mode.
So EMU does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and
CLKDM_CAN_FORCE_WAKEUP.
But the way it is implemented does not really allow that, because disable
hwsup imply setting state to OMAP34XX_CLKSTCTRL_DISABLE_AUTO.
void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
{
_clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst, cdoffs);
}
So if we want to
Re: oprofile and ARM A9 hardware counter
On Wed, May 09, 2012 at 10:45:08PM +0100, Jon Hunter wrote: Hi All, Hi Jon, I have posted my latest series here [1] based upon that from Will [2] which attempts to fix the EMU CD based upon the inputs from this thread. It is working on my omap4460 panda. Hopefully Ming and/or Will can also test. I know that Ming is out this week but said he can test next week. Many thanks to you (+Kevin, Benoit, Paul and co) for persevering with this. If I can get my hands on a Panda, I'll see if I can test something this week. Any particular tests you want me to run to exercise the interaction with PM? Cheers, Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Thu, May 10, 2012 at 10:44 AM, Will Deacon will.dea...@arm.com wrote: On Wed, May 09, 2012 at 10:45:08PM +0100, Jon Hunter wrote: Hi All, Hi Jon, I have posted my latest series here [1] based upon that from Will [2] which attempts to fix the EMU CD based upon the inputs from this thread. It is working on my omap4460 panda. Hopefully Ming and/or Will can also test. I know that Ming is out this week but said he can test next week. Many thanks to you (+Kevin, Benoit, Paul and co) for persevering with this. If I can get my hands on a Panda, I'll see if I can test something this week. Any particular tests you want me to run to exercise the interaction with PM? Cheers, I would like to get the final patch (on top of Ming's) so I can test this on my Panda board too. Thanks. Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Jon Hunter jon-hun...@ti.com writes: [...] I have posted my latest series here [1] based upon that from Will [2] which attempts to fix the EMU CD based upon the inputs from this thread. It is working on my omap4460 panda. There are some differences between 4430 and 4460 here. Can you test on 4430 as well? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Will,
On 05/10/2012 03:44 AM, Will Deacon wrote:
On Wed, May 09, 2012 at 10:45:08PM +0100, Jon Hunter wrote:
Hi All,
Hi Jon,
I have posted my latest series here [1] based upon that from Will [2]
which attempts to fix the EMU CD based upon the inputs from this thread.
It is working on my omap4460 panda. Hopefully Ming and/or Will can also
test. I know that Ming is out this week but said he can test next week.
Many thanks to you (+Kevin, Benoit, Paul and co) for persevering with this.
If I can get my hands on a Panda, I'll see if I can test something this
week. Any particular tests you want me to run to exercise the interaction
with PM?
May be Kevin and Paul have some suggestions, but I am not sure what PM modes
are currently supported for OMAP4 in the linux-omap master branch.
For my testing I have just been reading the PM_EMU_PWRSTST register which shows
the power state of the EMU power domain. It should read 3 when the power domain
is ON and 0 when it is off. I did something like the following (dumping all EMU
clock and power domain registers).
Cheers
Jon
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index b02aa81..41cb2fa 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -437,8 +437,25 @@ static struct omap_device_pm_latency omap_pmu_latency[] = {
static struct cti omap4_cti[2];
static struct platform_device *pmu_dev;
+static inline void dump_emu(char *s, int d)
+{
+ pr_info(%s-%d: CM_EMU_CLKSTCTRL = 0x%x\n, s, d,
+ __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307A00)));
+ pr_info(%s-%d: CM_EMU_DYNAMICDEP = 0x%x\n, s, d,
+ __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307A08)));
+ pr_info(%s-%d: CM_EMU_DEBUGSS_CLKCTRL = 0x%x\n, s, d,
+ __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307A20)));
+ pr_info(%s-%d: PM_EMU_PWRSTCTRL = 0x%x\n, s, d,
+ __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307900)));
+ pr_info(%s-%d: PM_EMU_PWRSTST = 0x%x\n, s, d,
+ __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307904)));
+ pr_info(%s-%d: RM_EMU_DEBUGSS_CONTEXT = 0x%x\n, s, d,
+ __raw_readl(OMAP2_L4_IO_ADDRESS(0x4A307924)));
+
+}
static void omap4_enable_cti(int irq)
{
+ dump_emu((char *)__func__, __LINE__);
pm_runtime_get_sync(pmu_dev-dev);
if (irq == OMAP44XX_IRQ_CTI0) {
/* configure CTI0 for pmu irq routing */
@@ -451,15 +468,18 @@ static void omap4_enable_cti(int irq)
cti_map_trigger(omap4_cti[1], 1, 6, 2);
cti_enable(omap4_cti[1]);
}
+ dump_emu((char *)__func__, __LINE__);
}
static void omap4_disable_cti(int irq)
{
+ dump_emu((char *)__func__, __LINE__);
if (irq == OMAP44XX_IRQ_CTI0)
cti_disable(omap4_cti[0]);
else if (irq == OMAP44XX_IRQ_CTI1)
cti_disable(omap4_cti[1]);
pm_runtime_put(pmu_dev-dev);
+ dump_emu((char *)__func__, __LINE__);
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Kevin, On 05/10/2012 09:12 AM, Kevin Hilman wrote: Jon Hunter jon-hun...@ti.com writes: [...] I have posted my latest series here [1] based upon that from Will [2] which attempts to fix the EMU CD based upon the inputs from this thread. It is working on my omap4460 panda. There are some differences between 4430 and 4460 here. Can you test on 4430 as well? No problem. I tested on an OMAP4430 ES2.2 EMU blaze this morning and it is also working. By the way, from an EMU power domain perspective the omap4430 and omap4460 behave the same, that is the PD is always set to OFF state and so will transition to OFF when ever the EMU CD idles. So same problem exists when using PMU and CTI. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Kevin and Jon,
On 5/8/2012 11:22 PM, Kevin Hilman wrote:
Jon Hunterjon-hun...@ti.com writes:
Hi Benoit,
On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
[...]
P.S. Please note there is also already a different fix in mainline for
the EMU clkdm data from Paul which adds the force wakeup flag and
removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
because the hardware is capable.)
Hmmm ... yes saw this, and you will have to excuse me as I don't fully
follow the logic here. In fact, I am thinking we want the opposite ;-)
From looking, into this it seems to me that when PMU is running we want
the EMU clock domain in software-wakeup state and when PMU is not
running we want in the hardware auto state.
So far, I'm with you.
By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
domain it is put right back into the HW_AUTO state
This is only because it was in the HWSUP state when _enable was called.
If clkdm_deny_idle() is used, that behavior will change.
and hence PMU is
not working (see _enable() function in
arch/arm/mach-omap2/omap_hwmod.c)
So really what I think we want is to remove the ENABLE_AUTO flag to keep
the clock domain in software wake-up and use the DISABLE_AUTO flag to
put the clock domain back in HW_AUTO (note this requires a patch to
perform this 2nd part).
Well, Paul will have to comment here for the final word, but IIUC, the
hwmod flags are supposed to indicate only what the HW is capable of. If
we want to change the runtime behavior, we nee to use (or add) APIs to
change the beahvior. In this case, clkdm_allow_idle(),
clkdm_deny_idle() are probably what is needed here.
Yes, indeed, we should not hack the flags to fix that kind of issue. The
flags describe what the HW is capable of, and the EMU CD can support
HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
only valid next power state is OFF, meaning that no retention mode is
supported. So any transition to idle will go to OFF and lead to a reset
upon wakeup.
No hacking intended here, just getting the flags correct ;-)
So let me start from the beginning ...
1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
SW_WKUP.
2. When the EMU CD is active (due to something like PMU), we want to
keep the CD in the SW_WKUP state, otherwise we can automatically
transition to idle and reset the IP (at least for omap4430).
3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
state because SW_SLEEP is NOT supported.
In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
set then the omap_pm_clkdms_setup() function will place the CD into
HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
hwmod _enable() is called it is in the HW_AUTO state and so it is
allowed to idle. This is not what we want. Do you agree?
If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
then I do not have the above problem.
To be honest, with you the more I look and test the code, the more
confused I am by the definition of the CLKDM_CAN_HWSUP ...
#define CLKDM_CAN_HWSUP (CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
When I look at where these flags are used, I see that
CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
Are the above the correct definitions?
Not quite.
These flags describe the capabilities as defined in CLKTRCTRL field of
the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)
Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
it's described as The automatic hardware-supervised mode is disabled
Yeah, in fact this is the source of the current confusion for my point of view.
We chat about that with Paul some time back.
EMU CD does support HW_AUTO and SW_WKUP, so it means that if you want to
disable the AUTO mode you can use the SW_WKUP.
Assuming that CLKDM_CAN_DISABLE_AUTO is equivalent to NO_SLEEP is thus not
correct. In fact any state != HW_AUTO should be considered a non-automatic mode.
So EMU does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and
CLKDM_CAN_FORCE_WAKEUP.
But the way it is implemented does not really allow that, because disable hwsup
imply setting state to OMAP34XX_CLKSTCTRL_DISABLE_AUTO.
void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
{
_clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst, cdoffs);
}
So if we want to allow that, some code change are needed in order to set the
clkdm mode to
Re: oprofile and ARM A9 hardware counter
Hi Benoit,
On 05/09/2012 05:58 AM, Cousson, Benoit wrote:
Hi Kevin and Jon,
On 5/8/2012 11:22 PM, Kevin Hilman wrote:
Jon Hunterjon-hun...@ti.com writes:
Hi Benoit,
On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
[...]
P.S. Please note there is also already a different fix in mainline for
the EMU clkdm data from Paul which adds the force wakeup flag and
removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
because the hardware is capable.)
Hmmm ... yes saw this, and you will have to excuse me as I don't fully
follow the logic here. In fact, I am thinking we want the opposite ;-)
From looking, into this it seems to me that when PMU is running we want
the EMU clock domain in software-wakeup state and when PMU is not
running we want in the hardware auto state.
So far, I'm with you.
By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
domain it is put right back into the HW_AUTO state
This is only because it was in the HWSUP state when _enable was called.
If clkdm_deny_idle() is used, that behavior will change.
and hence PMU is
not working (see _enable() function in
arch/arm/mach-omap2/omap_hwmod.c)
So really what I think we want is to remove the ENABLE_AUTO flag to keep
the clock domain in software wake-up and use the DISABLE_AUTO flag to
put the clock domain back in HW_AUTO (note this requires a patch to
perform this 2nd part).
Well, Paul will have to comment here for the final word, but IIUC, the
hwmod flags are supposed to indicate only what the HW is capable of. If
we want to change the runtime behavior, we nee to use (or add) APIs to
change the beahvior. In this case, clkdm_allow_idle(),
clkdm_deny_idle() are probably what is needed here.
Yes, indeed, we should not hack the flags to fix that kind of issue. The
flags describe what the HW is capable of, and the EMU CD can support
HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
only valid next power state is OFF, meaning that no retention mode is
supported. So any transition to idle will go to OFF and lead to a reset
upon wakeup.
No hacking intended here, just getting the flags correct ;-)
So let me start from the beginning ...
1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
SW_WKUP.
2. When the EMU CD is active (due to something like PMU), we want to
keep the CD in the SW_WKUP state, otherwise we can automatically
transition to idle and reset the IP (at least for omap4430).
3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
state because SW_SLEEP is NOT supported.
In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
set then the omap_pm_clkdms_setup() function will place the CD into
HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
hwmod _enable() is called it is in the HW_AUTO state and so it is
allowed to idle. This is not what we want. Do you agree?
If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
then I do not have the above problem.
To be honest, with you the more I look and test the code, the more
confused I am by the definition of the CLKDM_CAN_HWSUP ...
#define CLKDM_CAN_HWSUP (CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
When I look at where these flags are used, I see that
CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
Are the above the correct definitions?
Not quite.
These flags describe the capabilities as defined in CLKTRCTRL field of
the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)
Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
it's described as The automatic hardware-supervised mode is disabled
Yeah, in fact this is the source of the current confusion for my point of
view.
We chat about that with Paul some time back.
EMU CD does support HW_AUTO and SW_WKUP, so it means that if you want to
disable the AUTO mode you can use the SW_WKUP.
Assuming that CLKDM_CAN_DISABLE_AUTO is equivalent to NO_SLEEP is thus not
correct. In fact any state != HW_AUTO should be considered a non-automatic
mode.
So EMU does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and
CLKDM_CAN_FORCE_WAKEUP.
But the way it is implemented does not really allow that, because disable
hwsup imply setting state to OMAP34XX_CLKSTCTRL_DISABLE_AUTO.
void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
{
_clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst, cdoffs);
}
So if we want to allow that,
Re: oprofile and ARM A9 hardware counter
On 05/09/2012 01:04 PM, Jon Hunter wrote:
Hi Benoit,
On 05/09/2012 05:58 AM, Cousson, Benoit wrote:
Hi Kevin and Jon,
On 5/8/2012 11:22 PM, Kevin Hilman wrote:
Jon Hunterjon-hun...@ti.com writes:
Hi Benoit,
On 05/08/2012 06:01 AM, Cousson, Benoit wrote:
[...]
P.S. Please note there is also already a different fix in mainline for
the EMU clkdm data from Paul which adds the force wakeup flag and
removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag,
because the hardware is capable.)
Hmmm ... yes saw this, and you will have to excuse me as I don't fully
follow the logic here. In fact, I am thinking we want the opposite ;-)
From looking, into this it seems to me that when PMU is running we
want
the EMU clock domain in software-wakeup state and when PMU is not
running we want in the hardware auto state.
So far, I'm with you.
By keeping the ENABLE_AUTO flag set, as soon as we enable the clock
domain it is put right back into the HW_AUTO state
This is only because it was in the HWSUP state when _enable was called.
If clkdm_deny_idle() is used, that behavior will change.
and hence PMU is
not working (see _enable() function in
arch/arm/mach-omap2/omap_hwmod.c)
So really what I think we want is to remove the ENABLE_AUTO flag to keep
the clock domain in software wake-up and use the DISABLE_AUTO flag to
put the clock domain back in HW_AUTO (note this requires a patch to
perform this 2nd part).
Well, Paul will have to comment here for the final word, but IIUC, the
hwmod flags are supposed to indicate only what the HW is capable of. If
we want to change the runtime behavior, we nee to use (or add) APIs to
change the beahvior. In this case, clkdm_allow_idle(),
clkdm_deny_idle() are probably what is needed here.
Yes, indeed, we should not hack the flags to fix that kind of issue. The
flags describe what the HW is capable of, and the EMU CD can support
HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the
only valid next power state is OFF, meaning that no retention mode is
supported. So any transition to idle will go to OFF and lead to a reset
upon wakeup.
No hacking intended here, just getting the flags correct ;-)
So let me start from the beginning ...
1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
SW_WKUP.
2. When the EMU CD is active (due to something like PMU), we want to
keep the CD in the SW_WKUP state, otherwise we can automatically
transition to idle and reset the IP (at least for omap4430).
3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
state because SW_SLEEP is NOT supported.
In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
set then the omap_pm_clkdms_setup() function will place the CD into
HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
hwmod _enable() is called it is in the HW_AUTO state and so it is
allowed to idle. This is not what we want. Do you agree?
If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
then I do not have the above problem.
To be honest, with you the more I look and test the code, the more
confused I am by the definition of the CLKDM_CAN_HWSUP ...
#define CLKDM_CAN_HWSUP(CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
When I look at where these flags are used, I see that
CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ...
CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
Are the above the correct definitions?
Not quite.
These flags describe the capabilities as defined in CLKTRCTRL field of
the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)
Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
it's described as The automatic hardware-supervised mode is disabled
Yeah, in fact this is the source of the current confusion for my point of
view.
We chat about that with Paul some time back.
EMU CD does support HW_AUTO and SW_WKUP, so it means that if you want to
disable the AUTO mode you can use the SW_WKUP.
Assuming that CLKDM_CAN_DISABLE_AUTO is equivalent to NO_SLEEP is thus not
correct. In fact any state != HW_AUTO should be considered a non-automatic
mode.
So EMU does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and
CLKDM_CAN_FORCE_WAKEUP.
But the way it is implemented does not really allow that, because disable
hwsup imply setting state to OMAP34XX_CLKSTCTRL_DISABLE_AUTO.
void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
{
_clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst,
Re: oprofile and ARM A9 hardware counter
Hi All,
On 05/09/2012 02:28 PM, Jon Hunter wrote:
[...]
No hacking intended here, just getting the flags correct ;-)
So let me start from the beginning ...
1. I agree that for the EMU CD that the valid HW states are HW_AUTO and
SW_WKUP.
2. When the EMU CD is active (due to something like PMU), we want to
keep the CD in the SW_WKUP state, otherwise we can automatically
transition to idle and reset the IP (at least for omap4430).
3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO
state because SW_SLEEP is NOT supported.
In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled
and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is
set then the omap_pm_clkdms_setup() function will place the CD into
HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the
hwmod _enable() is called it is in the HW_AUTO state and so it is
allowed to idle. This is not what we want. Do you agree?
If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO,
then I do not have the above problem.
To be honest, with you the more I look and test the code, the more
confused I am by the definition of the CLKDM_CAN_HWSUP ...
#define CLKDM_CAN_HWSUP (CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO)
When I look at where these flags are used, I see that
CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and
CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that
...
CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active
CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active
Are the above the correct definitions?
Not quite.
These flags describe the capabilities as defined in CLKTRCTRL field of
the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL)
CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled)
CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP)
Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3
it's described as The automatic hardware-supervised mode is disabled
Yeah, in fact this is the source of the current confusion for my point of
view.
We chat about that with Paul some time back.
EMU CD does support HW_AUTO and SW_WKUP, so it means that if you want to
disable the AUTO mode you can use the SW_WKUP.
Assuming that CLKDM_CAN_DISABLE_AUTO is equivalent to NO_SLEEP is thus not
correct. In fact any state != HW_AUTO should be considered a non-automatic
mode.
So EMU does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and
CLKDM_CAN_FORCE_WAKEUP.
But the way it is implemented does not really allow that, because disable
hwsup imply setting state to OMAP34XX_CLKSTCTRL_DISABLE_AUTO.
void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs)
{
_clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst,
cdoffs);
}
So if we want to allow that, some code change are needed in order to set
the clkdm mode to OMAP34XX_CLKSTCTRL_FORCE_WAKEUP if
OMAP34XX_CLKSTCTRL_DISABLE_AUTO is not supported.
What is confusing to me is that the OMAP4 TRM doesn't list the NO_SLEEP
mode as supported by the EMU. It seems to me that if the IP supports
HW_AUTO, it should be able to be enabled *and* disabled.
No, not really, this is mostly OMAP3 legacy, and we do have plan to remove
these useless modes going forward. We can effectively disable AUTO mode by
going to FORCE_WAKEUP.
- 0x0 NO_SLEEP A clock domain sleep transition is never initiated,
irrespective of the hardware conditions.
- 0x1 SW_SLEEP A software-forced sleep transition. The transition is
initiated when the associated hardware conditions are satisfied
- 0x2 SW_WKUP A software-forced clock domain wake-up transition is
initiated, irrespective of the hardware conditions.
- 0x3 HW_AUTO Hardware-controlled automatic sleep and wake-up transition is
initiated by the PRCM module when the associated hardware conditions are
satisfied
On OMAP4, SW_SLEEP is equivalent to ENABLE_AUTO and
NO_SLEEP is equivalent to SW_WKUP. There are some slight differences inside
the HW, but in term of functionality this is mostly equivalent.
Bottom-line, if we fix the omap4_cminst_clkdm_disable_hwsup, we can
consider that the EMU CD does support CLKDM_CAN_ENABLE_AUTO,
CLKDM_CAN_DISABLE_AUTO and CLKDM_CAN_FORCE_WAKEUP, which is equivalent to
CLKDM_CAN_HWSUP | CLKDM_CAN_FORCE_WAKEUP.
Per our discussion and just to re-iterate here for OMAP4+ devices, we
should have ...
CAN_DISABLE_AUTO -- SW_WKUP
CAN_ENABLE_AUTO -- HW_AUTO
CAN_FORCE_WAKEUP -- SW_WKUP
CAN_FORCE_SLEEP -- HW_AUTO
Hence, the NO_SLEEP and SW_SLEEP should not be used for OMAP4+ (per the
equivalents highlighted above). At least that is the current theory :-)
I realise now the the l4cfg CD does not support SW_WKUP and so I guess
we still need NO_SLEEP in that case. So that would break the above
mapping and we
Re: oprofile and ARM A9 hardware counter
Hi Kevin Jon, On 5/8/2012 1:28 AM, Kevin Hilman wrote: Jon Hunterjon-hun...@ti.com writes: Hi Kevin, On 05/07/2012 12:15 PM, Kevin Hilman wrote: Jon Hunterjon-hun...@ti.com writes: Hi Will, On 04/26/2012 01:07 PM, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote: Part of the problem is that the clockdomain data for the emu_sys clockdomain is wrong. Here's something to try to fix it. It might just be enough to get it to work. Hmm, doesn't seem to work but I do see the following in dmesg when I try to use perf: powerdomain: waited too long for powerdomain emu_pwrdm to complete transition which is new with your patch. Sorry to nag, but does anybody have a clue where to go from here? I can start digging in the OMAP PM code, but it's all new territory for me. I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list. Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. Cheers Jon From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001 From: Jon Hunterjon-hun...@ti.com Date: Fri, 4 May 2012 16:48:45 -0500 Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition to the enabled and disabled state. This means that as soon as we force a software wake-up on the clock domain, the clock domain will be allowed to idle and put back into the hardware auto state. For the EMU clock domain this is not what we want. We want to keep the clock domain in the software wakeup state while the clock domain is being used and put it back in to the hardware auto state when we have finished using the clock domain. Signed-off-by: Jon Hunterjon-hun...@ti.com With this patch, how is the clkdm ever idled? It does not! Sorry, I was so engrossed with figuring out why the EMU clkdm was being idled as soon as it was enabled, I forgot to check if is ever disabled once we terminated perf :-( IIUC, your patch will get PMU interrupts working, but similarily to previous patches in this thread, it works because it *never* allows the EMU clkdm to idle. This is not a mergeable solution because it will not allow CORE retention (and thus full-chip retention.) Right! What we need is a solution that allows the clkdm to idle, and then to be reinitialzed when it wakes up. Due to the way (I understand) resets in the debugss, allowing the clkdm to idle will cause a reset, so the PMU/CTI interrupts need to be reinitialzied after wakeup. Yes exactly I see that now. I have prototyped the 3 patches and this is working AND the EMU clkdm does go back to idle. I can send out to the list for review. Perfect, thanks. Kevin P.S. Please note there is also already a different fix in mainline for the EMU clkdm data from Paul which adds the force wakeup flag and removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag, because the hardware is capable.) Hmmm ... yes saw this, and you will have to excuse me as I don't fully follow the logic here. In fact, I am thinking we want the opposite ;-) From looking, into this it seems to me that when PMU is running we want the EMU clock domain in software-wakeup state and when PMU is not running we want in the hardware auto state. So far, I'm with you. By keeping the ENABLE_AUTO flag set, as soon as we enable the clock domain it is put right back into the HW_AUTO state This is only because it was in the HWSUP state when _enable was called. If clkdm_deny_idle() is used, that behavior will change. and hence PMU is not working (see _enable() function in arch/arm/mach-omap2/omap_hwmod.c) So really what I think we want is to remove the ENABLE_AUTO flag to keep the clock domain in software wake-up and use the DISABLE_AUTO flag to put the clock domain back in HW_AUTO (note this requires a patch to perform this 2nd part). Well, Paul will have to comment here for the final word, but IIUC, the hwmod flags are supposed to indicate only what the HW is capable of. If we want to change the runtime behavior, we nee to use (or add) APIs to change the beahvior. In this case, clkdm_allow_idle(), clkdm_deny_idle() are probably what is needed here. Yes, indeed, we should not hack the flags to fix that kind of issue. The flags describe what the HW is capable of, and the EMU CD can support HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid next power state
Re: oprofile and ARM A9 hardware counter
Hi Benoit, On Tue, May 8, 2012 at 1:01 PM, Cousson, Benoit b-cous...@ti.com wrote: Hi Kevin Jon, On 5/8/2012 1:28 AM, Kevin Hilman wrote: Jon Hunterjon-hun...@ti.com writes: Hi Kevin, On 05/07/2012 12:15 PM, Kevin Hilman wrote: Jon Hunterjon-hun...@ti.com writes: Hi Will, On 04/26/2012 01:07 PM, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote: Part of the problem is that the clockdomain data for the emu_sys clockdomain is wrong. Here's something to try to fix it. It might just be enough to get it to work. Hmm, doesn't seem to work but I do see the following in dmesg when I try to use perf: powerdomain: waited too long for powerdomain emu_pwrdm to complete transition which is new with your patch. Sorry to nag, but does anybody have a clue where to go from here? I can start digging in the OMAP PM code, but it's all new territory for me. I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list. Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. Cheers Jon From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001 From: Jon Hunterjon-hun...@ti.com Date: Fri, 4 May 2012 16:48:45 -0500 Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition to the enabled and disabled state. This means that as soon as we force a software wake-up on the clock domain, the clock domain will be allowed to idle and put back into the hardware auto state. For the EMU clock domain this is not what we want. We want to keep the clock domain in the software wakeup state while the clock domain is being used and put it back in to the hardware auto state when we have finished using the clock domain. Signed-off-by: Jon Hunterjon-hun...@ti.com With this patch, how is the clkdm ever idled? It does not! Sorry, I was so engrossed with figuring out why the EMU clkdm was being idled as soon as it was enabled, I forgot to check if is ever disabled once we terminated perf :-( IIUC, your patch will get PMU interrupts working, but similarily to previous patches in this thread, it works because it *never* allows the EMU clkdm to idle. This is not a mergeable solution because it will not allow CORE retention (and thus full-chip retention.) Right! What we need is a solution that allows the clkdm to idle, and then to be reinitialzed when it wakes up. Due to the way (I understand) resets in the debugss, allowing the clkdm to idle will cause a reset, so the PMU/CTI interrupts need to be reinitialzied after wakeup. Yes exactly I see that now. I have prototyped the 3 patches and this is working AND the EMU clkdm does go back to idle. I can send out to the list for review. Perfect, thanks. Kevin P.S. Please note there is also already a different fix in mainline for the EMU clkdm data from Paul which adds the force wakeup flag and removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag, because the hardware is capable.) Hmmm ... yes saw this, and you will have to excuse me as I don't fully follow the logic here. In fact, I am thinking we want the opposite ;-) From looking, into this it seems to me that when PMU is running we want the EMU clock domain in software-wakeup state and when PMU is not running we want in the hardware auto state. So far, I'm with you. By keeping the ENABLE_AUTO flag set, as soon as we enable the clock domain it is put right back into the HW_AUTO state This is only because it was in the HWSUP state when _enable was called. If clkdm_deny_idle() is used, that behavior will change. and hence PMU is not working (see _enable() function in arch/arm/mach-omap2/omap_hwmod.c) So really what I think we want is to remove the ENABLE_AUTO flag to keep the clock domain in software wake-up and use the DISABLE_AUTO flag to put the clock domain back in HW_AUTO (note this requires a patch to perform this 2nd part). Well, Paul will have to comment here for the final word, but IIUC, the hwmod flags are supposed to indicate only what the HW is capable of. If we want to change the runtime behavior, we nee to use (or add) APIs to change the beahvior. In this case, clkdm_allow_idle(), clkdm_deny_idle() are probably what is needed here. Yes, indeed, we should not hack the flags to fix that kind of issue.
Re: oprofile and ARM A9 hardware counter
Salut Jean, On 5/8/2012 1:23 PM, Jean Pihet wrote: Hi Benoit, On Tue, May 8, 2012 at 1:01 PM, Cousson, Benoitb-cous...@ti.com wrote: Hi Kevin Jon, On 5/8/2012 1:28 AM, Kevin Hilman wrote: Jon Hunterjon-hun...@ti.comwrites: Hi Kevin, On 05/07/2012 12:15 PM, Kevin Hilman wrote: Jon Hunterjon-hun...@ti.comwrites: Hi Will, On 04/26/2012 01:07 PM, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote: Part of the problem is that the clockdomain data for the emu_sys clockdomain is wrong. Here's something to try to fix it. It might just be enough to get it to work. Hmm, doesn't seem to work but I do see the following in dmesg when I try to use perf: powerdomain: waited too long for powerdomain emu_pwrdm to complete transition which is new with your patch. Sorry to nag, but does anybody have a clue where to go from here? I can start digging in the OMAP PM code, but it's all new territory for me. I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list. Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. Cheers Jon From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001 From: Jon Hunterjon-hun...@ti.com Date: Fri, 4 May 2012 16:48:45 -0500 Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition to the enabled and disabled state. This means that as soon as we force a software wake-up on the clock domain, the clock domain will be allowed to idle and put back into the hardware auto state. For the EMU clock domain this is not what we want. We want to keep the clock domain in the software wakeup state while the clock domain is being used and put it back in to the hardware auto state when we have finished using the clock domain. Signed-off-by: Jon Hunterjon-hun...@ti.com With this patch, how is the clkdm ever idled? It does not! Sorry, I was so engrossed with figuring out why the EMU clkdm was being idled as soon as it was enabled, I forgot to check if is ever disabled once we terminated perf :-( IIUC, your patch will get PMU interrupts working, but similarily to previous patches in this thread, it works because it *never* allows the EMU clkdm to idle. This is not a mergeable solution because it will not allow CORE retention (and thus full-chip retention.) Right! What we need is a solution that allows the clkdm to idle, and then to be reinitialzed when it wakes up. Due to the way (I understand) resets in the debugss, allowing the clkdm to idle will cause a reset, so the PMU/CTI interrupts need to be reinitialzied after wakeup. Yes exactly I see that now. I have prototyped the 3 patches and this is working AND the EMU clkdm does go back to idle. I can send out to the list for review. Perfect, thanks. Kevin P.S. Please note there is also already a different fix in mainline for the EMU clkdm data from Paul which adds the force wakeup flag and removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag, because the hardware is capable.) Hmmm ... yes saw this, and you will have to excuse me as I don't fully follow the logic here. In fact, I am thinking we want the opposite ;-) From looking, into this it seems to me that when PMU is running we want the EMU clock domain in software-wakeup state and when PMU is not running we want in the hardware auto state. So far, I'm with you. By keeping the ENABLE_AUTO flag set, as soon as we enable the clock domain it is put right back into the HW_AUTO state This is only because it was in the HWSUP state when _enable was called. If clkdm_deny_idle() is used, that behavior will change. and hence PMU is not working (see _enable() function in arch/arm/mach-omap2/omap_hwmod.c) So really what I think we want is to remove the ENABLE_AUTO flag to keep the clock domain in software wake-up and use the DISABLE_AUTO flag to put the clock domain back in HW_AUTO (note this requires a patch to perform this 2nd part). Well, Paul will have to comment here for the final word, but IIUC, the hwmod flags are supposed to indicate only what the HW is capable of. If we want to change the runtime behavior, we nee to use (or add) APIs to change the beahvior. In this case, clkdm_allow_idle(), clkdm_deny_idle() are probably what is needed here. Yes, indeed, we should not hack the flags to fix that kind of issue. The flags
Re: oprofile and ARM A9 hardware counter
On Tue, May 8, 2012 at 2:37 PM, Cousson, Benoit b-cous...@ti.com wrote: Salut Jean, On 5/8/2012 1:23 PM, Jean Pihet wrote: Hi Benoit, On Tue, May 8, 2012 at 1:01 PM, Cousson, Benoitb-cous...@ti.com wrote: Hi Kevin Jon, On 5/8/2012 1:28 AM, Kevin Hilman wrote: Jon Hunterjon-hun...@ti.com writes: Hi Kevin, On 05/07/2012 12:15 PM, Kevin Hilman wrote: Jon Hunterjon-hun...@ti.com writes: Hi Will, On 04/26/2012 01:07 PM, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote: Part of the problem is that the clockdomain data for the emu_sys clockdomain is wrong. Here's something to try to fix it. It might just be enough to get it to work. Hmm, doesn't seem to work but I do see the following in dmesg when I try to use perf: powerdomain: waited too long for powerdomain emu_pwrdm to complete transition which is new with your patch. Sorry to nag, but does anybody have a clue where to go from here? I can start digging in the OMAP PM code, but it's all new territory for me. I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list. Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. Cheers Jon From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001 From: Jon Hunterjon-hun...@ti.com Date: Fri, 4 May 2012 16:48:45 -0500 Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition to the enabled and disabled state. This means that as soon as we force a software wake-up on the clock domain, the clock domain will be allowed to idle and put back into the hardware auto state. For the EMU clock domain this is not what we want. We want to keep the clock domain in the software wakeup state while the clock domain is being used and put it back in to the hardware auto state when we have finished using the clock domain. Signed-off-by: Jon Hunterjon-hun...@ti.com With this patch, how is the clkdm ever idled? It does not! Sorry, I was so engrossed with figuring out why the EMU clkdm was being idled as soon as it was enabled, I forgot to check if is ever disabled once we terminated perf :-( IIUC, your patch will get PMU interrupts working, but similarily to previous patches in this thread, it works because it *never* allows the EMU clkdm to idle. This is not a mergeable solution because it will not allow CORE retention (and thus full-chip retention.) Right! What we need is a solution that allows the clkdm to idle, and then to be reinitialzed when it wakes up. Due to the way (I understand) resets in the debugss, allowing the clkdm to idle will cause a reset, so the PMU/CTI interrupts need to be reinitialzied after wakeup. Yes exactly I see that now. I have prototyped the 3 patches and this is working AND the EMU clkdm does go back to idle. I can send out to the list for review. Perfect, thanks. Kevin P.S. Please note there is also already a different fix in mainline for the EMU clkdm data from Paul which adds the force wakeup flag and removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag, because the hardware is capable.) Hmmm ... yes saw this, and you will have to excuse me as I don't fully follow the logic here. In fact, I am thinking we want the opposite ;-) From looking, into this it seems to me that when PMU is running we want the EMU clock domain in software-wakeup state and when PMU is not running we want in the hardware auto state. So far, I'm with you. By keeping the ENABLE_AUTO flag set, as soon as we enable the clock domain it is put right back into the HW_AUTO state This is only because it was in the HWSUP state when _enable was called. If clkdm_deny_idle() is used, that behavior will change. and hence PMU is not working (see _enable() function in arch/arm/mach-omap2/omap_hwmod.c) So really what I think we want is to remove the ENABLE_AUTO flag to keep the clock domain in software wake-up and use the DISABLE_AUTO flag to put the clock domain back in HW_AUTO (note this requires a patch to perform this 2nd part). Well, Paul will have to comment here for the final word, but IIUC, the hwmod flags are supposed to indicate only what the HW is capable of. If we want to change the runtime behavior, we nee to use (or add) APIs to change the
Re: oprofile and ARM A9 hardware counter
Jean Pihet jean.pi...@newoldbits.com writes: [...] Yes, indeed, we should not hack the flags to fix that kind of issue. The flags describe what the HW is capable of, and the EMU CD can support HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid next power state is OFF, meaning that no retention mode is supported. So any transition to idle will go to OFF and lead to a reset upon wakeup. That being said, being able to transition to OFF during idle is a perfectly valid state for most powerdomain in OMAP anyway, so we should be able to restore from OFF mode smoothly. It looks to me that what is missing here is *just* a restore path in the PMU/CTI code. But I'm probably missing some nasty details in this issue :-) Although it is perfectly feasible to have a seamless transition of the EMU power domain, I think the PMU counters will not be accurate anymore since they stop counting events when going to OFF and re-start after the state restore. Good point, but I think the PMU might still works fine because located inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is going to OFF and thus will be reset. Ever better point ;p Thanks for the precision. In any case my point was: can we allow the EMU CD to go OFF or prevent it from doing so? We need to answer that question first. The idea I've suggested is to use runtime PM for this. As long as the PMU is in use, it will be runtime PM enabled (and not allowed to go into HWSUP idle.) When it is not used, it will be allowed to HWSUP idle, and then be reset. The next time it is needed, the runtime resume will need to do a full re-init. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On 5/8/2012 4:00 PM, Kevin Hilman wrote: Jean Pihetjean.pi...@newoldbits.com writes: [...] Yes, indeed, we should not hack the flags to fix that kind of issue. The flags describe what the HW is capable of, and the EMU CD can support HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid next power state is OFF, meaning that no retention mode is supported. So any transition to idle will go to OFF and lead to a reset upon wakeup. That being said, being able to transition to OFF during idle is a perfectly valid state for most powerdomain in OMAP anyway, so we should be able to restore from OFF mode smoothly. It looks to me that what is missing here is *just* a restore path in the PMU/CTI code. But I'm probably missing some nasty details in this issue :-) Although it is perfectly feasible to have a seamless transition of the EMU power domain, I think the PMU counters will not be accurate anymore since they stop counting events when going to OFF and re-start after the state restore. Good point, but I think the PMU might still works fine because located inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is going to OFF and thus will be reset. Ever better point ;p Thanks for the precision. In any case my point was: can we allow the EMU CD to go OFF or prevent it from doing so? We need to answer that question first. The idea I've suggested is to use runtime PM for this. As long as the PMU is in use, it will be runtime PM enabled (and not allowed to go into HWSUP idle.) When it is not used, it will be allowed to HWSUP idle, and then be reset. The next time it is needed, the runtime resume will need to do a full re-init. Oh, but does that mean that this driver is not pm_runtime adapted yet? Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Cousson, Benoit b-cous...@ti.com writes: On 5/8/2012 4:00 PM, Kevin Hilman wrote: Jean Pihetjean.pi...@newoldbits.com writes: [...] Yes, indeed, we should not hack the flags to fix that kind of issue. The flags describe what the HW is capable of, and the EMU CD can support HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid next power state is OFF, meaning that no retention mode is supported. So any transition to idle will go to OFF and lead to a reset upon wakeup. That being said, being able to transition to OFF during idle is a perfectly valid state for most powerdomain in OMAP anyway, so we should be able to restore from OFF mode smoothly. It looks to me that what is missing here is *just* a restore path in the PMU/CTI code. But I'm probably missing some nasty details in this issue :-) Although it is perfectly feasible to have a seamless transition of the EMU power domain, I think the PMU counters will not be accurate anymore since they stop counting events when going to OFF and re-start after the state restore. Good point, but I think the PMU might still works fine because located inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is going to OFF and thus will be reset. Ever better point ;p Thanks for the precision. In any case my point was: can we allow the EMU CD to go OFF or prevent it from doing so? We need to answer that question first. The idea I've suggested is to use runtime PM for this. As long as the PMU is in use, it will be runtime PM enabled (and not allowed to go into HWSUP idle.) When it is not used, it will be allowed to HWSUP idle, and then be reset. The next time it is needed, the runtime resume will need to do a full re-init. Oh, but does that mean that this driver is not pm_runtime adapted yet? Actually, it is. Ming Lei has done it. Currently, Will has collected this[1] and is waiting (patiently) for us to produce a real fix that doesn't kill PM in the process. Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Benoit, On 05/08/2012 06:01 AM, Cousson, Benoit wrote: [...] P.S. Please note there is also already a different fix in mainline for the EMU clkdm data from Paul which adds the force wakeup flag and removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag, because the hardware is capable.) Hmmm ... yes saw this, and you will have to excuse me as I don't fully follow the logic here. In fact, I am thinking we want the opposite ;-) From looking, into this it seems to me that when PMU is running we want the EMU clock domain in software-wakeup state and when PMU is not running we want in the hardware auto state. So far, I'm with you. By keeping the ENABLE_AUTO flag set, as soon as we enable the clock domain it is put right back into the HW_AUTO state This is only because it was in the HWSUP state when _enable was called. If clkdm_deny_idle() is used, that behavior will change. and hence PMU is not working (see _enable() function in arch/arm/mach-omap2/omap_hwmod.c) So really what I think we want is to remove the ENABLE_AUTO flag to keep the clock domain in software wake-up and use the DISABLE_AUTO flag to put the clock domain back in HW_AUTO (note this requires a patch to perform this 2nd part). Well, Paul will have to comment here for the final word, but IIUC, the hwmod flags are supposed to indicate only what the HW is capable of. If we want to change the runtime behavior, we nee to use (or add) APIs to change the beahvior. In this case, clkdm_allow_idle(), clkdm_deny_idle() are probably what is needed here. Yes, indeed, we should not hack the flags to fix that kind of issue. The flags describe what the HW is capable of, and the EMU CD can support HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid next power state is OFF, meaning that no retention mode is supported. So any transition to idle will go to OFF and lead to a reset upon wakeup. No hacking intended here, just getting the flags correct ;-) So let me start from the beginning ... 1. I agree that for the EMU CD that the valid HW states are HW_AUTO and SW_WKUP. 2. When the EMU CD is active (due to something like PMU), we want to keep the CD in the SW_WKUP state, otherwise we can automatically transition to idle and reset the IP (at least for omap4430). 3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO state because SW_SLEEP is NOT supported. In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is set then the omap_pm_clkdms_setup() function will place the CD into HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the hwmod _enable() is called it is in the HW_AUTO state and so it is allowed to idle. This is not what we want. Do you agree? If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO, then I do not have the above problem. To be honest, with you the more I look and test the code, the more confused I am by the definition of the CLKDM_CAN_HWSUP ... #define CLKDM_CAN_HWSUP (CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO) When I look at where these flags are used, I see that CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ... CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active Are the above the correct definitions? If so why is CLKDM_CAN_HWSUP defined as above? So may be I just needed to understand how these flags are intended to be used. That being said, being able to transition to OFF during idle is a perfectly valid state for most powerdomain in OMAP anyway, so we should be able to restore from OFF mode smoothly. It looks to me that what is missing here is *just* a restore path in the PMU/CTI code. But I'm probably missing some nasty details in this issue :-) Yes agree with this too. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On 05/08/2012 11:18 AM, Kevin Hilman wrote: Cousson, Benoit b-cous...@ti.com writes: On 5/8/2012 4:00 PM, Kevin Hilman wrote: Jean Pihetjean.pi...@newoldbits.com writes: [...] Yes, indeed, we should not hack the flags to fix that kind of issue. The flags describe what the HW is capable of, and the EMU CD can support HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid next power state is OFF, meaning that no retention mode is supported. So any transition to idle will go to OFF and lead to a reset upon wakeup. That being said, being able to transition to OFF during idle is a perfectly valid state for most powerdomain in OMAP anyway, so we should be able to restore from OFF mode smoothly. It looks to me that what is missing here is *just* a restore path in the PMU/CTI code. But I'm probably missing some nasty details in this issue :-) Although it is perfectly feasible to have a seamless transition of the EMU power domain, I think the PMU counters will not be accurate anymore since they stop counting events when going to OFF and re-start after the state restore. Good point, but I think the PMU might still works fine because located inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is going to OFF and thus will be reset. Ever better point ;p Thanks for the precision. In any case my point was: can we allow the EMU CD to go OFF or prevent it from doing so? We need to answer that question first. The idea I've suggested is to use runtime PM for this. As long as the PMU is in use, it will be runtime PM enabled (and not allowed to go into HWSUP idle.) When it is not used, it will be allowed to HWSUP idle, and then be reset. The next time it is needed, the runtime resume will need to do a full re-init. Oh, but does that mean that this driver is not pm_runtime adapted yet? Actually, it is. Ming Lei has done it. Currently, Will has collected this[1] and is waiting (patiently) for us to produce a real fix that doesn't kill PM in the process. I had to make a couple mods to Ming's patches but I do have something working now that _should_ not break PM. However, per my previous email (in response to Benoit's) I am struggling with the definition of the CLKDM_CAN_XX_AUTO flags to know the correct way to fix this. I was going to send out my patches, but I wanted to get some more feedback on this first. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Jon Hunter jon-hun...@ti.com writes: Hi Benoit, On 05/08/2012 06:01 AM, Cousson, Benoit wrote: [...] P.S. Please note there is also already a different fix in mainline for the EMU clkdm data from Paul which adds the force wakeup flag and removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag, because the hardware is capable.) Hmmm ... yes saw this, and you will have to excuse me as I don't fully follow the logic here. In fact, I am thinking we want the opposite ;-) From looking, into this it seems to me that when PMU is running we want the EMU clock domain in software-wakeup state and when PMU is not running we want in the hardware auto state. So far, I'm with you. By keeping the ENABLE_AUTO flag set, as soon as we enable the clock domain it is put right back into the HW_AUTO state This is only because it was in the HWSUP state when _enable was called. If clkdm_deny_idle() is used, that behavior will change. and hence PMU is not working (see _enable() function in arch/arm/mach-omap2/omap_hwmod.c) So really what I think we want is to remove the ENABLE_AUTO flag to keep the clock domain in software wake-up and use the DISABLE_AUTO flag to put the clock domain back in HW_AUTO (note this requires a patch to perform this 2nd part). Well, Paul will have to comment here for the final word, but IIUC, the hwmod flags are supposed to indicate only what the HW is capable of. If we want to change the runtime behavior, we nee to use (or add) APIs to change the beahvior. In this case, clkdm_allow_idle(), clkdm_deny_idle() are probably what is needed here. Yes, indeed, we should not hack the flags to fix that kind of issue. The flags describe what the HW is capable of, and the EMU CD can support HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid next power state is OFF, meaning that no retention mode is supported. So any transition to idle will go to OFF and lead to a reset upon wakeup. No hacking intended here, just getting the flags correct ;-) So let me start from the beginning ... 1. I agree that for the EMU CD that the valid HW states are HW_AUTO and SW_WKUP. 2. When the EMU CD is active (due to something like PMU), we want to keep the CD in the SW_WKUP state, otherwise we can automatically transition to idle and reset the IP (at least for omap4430). 3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO state because SW_SLEEP is NOT supported. In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is set then the omap_pm_clkdms_setup() function will place the CD into HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the hwmod _enable() is called it is in the HW_AUTO state and so it is allowed to idle. This is not what we want. Do you agree? If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO, then I do not have the above problem. To be honest, with you the more I look and test the code, the more confused I am by the definition of the CLKDM_CAN_HWSUP ... #define CLKDM_CAN_HWSUP (CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO) When I look at where these flags are used, I see that CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ... CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active Are the above the correct definitions? Not quite. These flags describe the capabilities as defined in CLKTRCTRL field of the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL) CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled) CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP) Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3 it's described as The automatic hardware-supervised mode is disabled What is confusing to me is that the OMAP4 TRM doesn't list the NO_SLEEP mode as supported by the EMU. It seems to me that if the IP supports HW_AUTO, it should be able to be enabled *and* disabled. Maybe Paul/Benoit can clarify. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Jon Hunter jon-hun...@ti.com writes: On 05/08/2012 11:18 AM, Kevin Hilman wrote: Cousson, Benoit b-cous...@ti.com writes: On 5/8/2012 4:00 PM, Kevin Hilman wrote: Jean Pihetjean.pi...@newoldbits.com writes: [...] Yes, indeed, we should not hack the flags to fix that kind of issue. The flags describe what the HW is capable of, and the EMU CD can support HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid next power state is OFF, meaning that no retention mode is supported. So any transition to idle will go to OFF and lead to a reset upon wakeup. That being said, being able to transition to OFF during idle is a perfectly valid state for most powerdomain in OMAP anyway, so we should be able to restore from OFF mode smoothly. It looks to me that what is missing here is *just* a restore path in the PMU/CTI code. But I'm probably missing some nasty details in this issue :-) Although it is perfectly feasible to have a seamless transition of the EMU power domain, I think the PMU counters will not be accurate anymore since they stop counting events when going to OFF and re-start after the state restore. Good point, but I think the PMU might still works fine because located inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is going to OFF and thus will be reset. Ever better point ;p Thanks for the precision. In any case my point was: can we allow the EMU CD to go OFF or prevent it from doing so? We need to answer that question first. The idea I've suggested is to use runtime PM for this. As long as the PMU is in use, it will be runtime PM enabled (and not allowed to go into HWSUP idle.) When it is not used, it will be allowed to HWSUP idle, and then be reset. The next time it is needed, the runtime resume will need to do a full re-init. Oh, but does that mean that this driver is not pm_runtime adapted yet? Actually, it is. Ming Lei has done it. Currently, Will has collected this[1] and is waiting (patiently) for us to produce a real fix that doesn't kill PM in the process. I had to make a couple mods to Ming's patches but I do have something working now that _should_ not break PM. However, per my previous email (in response to Benoit's) I am struggling with the definition of the CLKDM_CAN_XX_AUTO flags to know the correct way to fix this. I was going to send out my patches, but I wanted to get some more feedback on this first. While waiting for feeback, if you set the flags to CAN_FORCE_WAKEUP and CAN_HWSUP, can you get the PMU interrupts working after an EMU CD idle transition (and reset.) Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Mon, 7 May 2012, Kevin Hilman wrote: Well, Paul will have to comment here for the final word, but IIUC, the hwmod flags are supposed to indicate only what the HW is capable of. s/hwmod/clockdomain/ in this case, but that's exactly right. The motivation is to allow this data to be autogenerated and to allow it to be verified against the TRM (assuming that the TRM is not wrong). If there's some weird hardware bug, the intention is to either add a special workaround flag so the bug doesn't get hidden, or to deal with it in the code in some way. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Wed, May 9, 2012 at 3:51 AM, Jon Hunter jon-hun...@ti.com wrote: I had to make a couple mods to Ming's patches but I do have something working now that _should_ not break PM. However, per my previous email (in response to Benoit's) I am struggling with the definition of the CLKDM_CAN_XX_AUTO flags to know the correct way to fix this. I was going to send out my patches, but I wanted to get some more feedback on this first. I can test your patch once I return home from business trip next week. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Kevin, On 05/08/2012 04:28 PM, Kevin Hilman wrote: Jon Hunter jon-hun...@ti.com writes: On 05/08/2012 11:18 AM, Kevin Hilman wrote: Cousson, Benoit b-cous...@ti.com writes: On 5/8/2012 4:00 PM, Kevin Hilman wrote: Jean Pihetjean.pi...@newoldbits.com writes: [...] Yes, indeed, we should not hack the flags to fix that kind of issue. The flags describe what the HW is capable of, and the EMU CD can support HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid next power state is OFF, meaning that no retention mode is supported. So any transition to idle will go to OFF and lead to a reset upon wakeup. That being said, being able to transition to OFF during idle is a perfectly valid state for most powerdomain in OMAP anyway, so we should be able to restore from OFF mode smoothly. It looks to me that what is missing here is *just* a restore path in the PMU/CTI code. But I'm probably missing some nasty details in this issue :-) Although it is perfectly feasible to have a seamless transition of the EMU power domain, I think the PMU counters will not be accurate anymore since they stop counting events when going to OFF and re-start after the state restore. Good point, but I think the PMU might still works fine because located inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is going to OFF and thus will be reset. Ever better point ;p Thanks for the precision. In any case my point was: can we allow the EMU CD to go OFF or prevent it from doing so? We need to answer that question first. The idea I've suggested is to use runtime PM for this. As long as the PMU is in use, it will be runtime PM enabled (and not allowed to go into HWSUP idle.) When it is not used, it will be allowed to HWSUP idle, and then be reset. The next time it is needed, the runtime resume will need to do a full re-init. Oh, but does that mean that this driver is not pm_runtime adapted yet? Actually, it is. Ming Lei has done it. Currently, Will has collected this[1] and is waiting (patiently) for us to produce a real fix that doesn't kill PM in the process. I had to make a couple mods to Ming's patches but I do have something working now that _should_ not break PM. However, per my previous email (in response to Benoit's) I am struggling with the definition of the CLKDM_CAN_XX_AUTO flags to know the correct way to fix this. I was going to send out my patches, but I wanted to get some more feedback on this first. While waiting for feeback, if you set the flags to CAN_FORCE_WAKEUP and CAN_HWSUP, can you get the PMU interrupts working after an EMU CD idle transition (and reset.) Unfortunately, not. By setting CAN_HWSUP, the EMU CD will be put back into HW_AUTO state when it is enabled. The hwmod _enable() function will first put the CD into SW_WKUP (because CAN_FORCE_WAKEUP is set), but because it was previously in HW_AUTO state AND CAN_ENABLE_AUTO is set it will be be put back into HW_AUTO again. Hence, we are back where we begun! CAN_ENABLE_AUTO is causing me a headache, because whenever you call clkdm_allow_idle, it will allow it to idle and this happens during the _enable() sequence :-( Does this make sense? Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Kevin, On 05/08/2012 04:22 PM, Kevin Hilman wrote: Jon Hunter jon-hun...@ti.com writes: Hi Benoit, On 05/08/2012 06:01 AM, Cousson, Benoit wrote: [...] P.S. Please note there is also already a different fix in mainline for the EMU clkdm data from Paul which adds the force wakeup flag and removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag, because the hardware is capable.) Hmmm ... yes saw this, and you will have to excuse me as I don't fully follow the logic here. In fact, I am thinking we want the opposite ;-) From looking, into this it seems to me that when PMU is running we want the EMU clock domain in software-wakeup state and when PMU is not running we want in the hardware auto state. So far, I'm with you. By keeping the ENABLE_AUTO flag set, as soon as we enable the clock domain it is put right back into the HW_AUTO state This is only because it was in the HWSUP state when _enable was called. If clkdm_deny_idle() is used, that behavior will change. and hence PMU is not working (see _enable() function in arch/arm/mach-omap2/omap_hwmod.c) So really what I think we want is to remove the ENABLE_AUTO flag to keep the clock domain in software wake-up and use the DISABLE_AUTO flag to put the clock domain back in HW_AUTO (note this requires a patch to perform this 2nd part). Well, Paul will have to comment here for the final word, but IIUC, the hwmod flags are supposed to indicate only what the HW is capable of. If we want to change the runtime behavior, we nee to use (or add) APIs to change the beahvior. In this case, clkdm_allow_idle(), clkdm_deny_idle() are probably what is needed here. Yes, indeed, we should not hack the flags to fix that kind of issue. The flags describe what the HW is capable of, and the EMU CD can support HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid next power state is OFF, meaning that no retention mode is supported. So any transition to idle will go to OFF and lead to a reset upon wakeup. No hacking intended here, just getting the flags correct ;-) So let me start from the beginning ... 1. I agree that for the EMU CD that the valid HW states are HW_AUTO and SW_WKUP. 2. When the EMU CD is active (due to something like PMU), we want to keep the CD in the SW_WKUP state, otherwise we can automatically transition to idle and reset the IP (at least for omap4430). 3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO state because SW_SLEEP is NOT supported. In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is set then the omap_pm_clkdms_setup() function will place the CD into HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the hwmod _enable() is called it is in the HW_AUTO state and so it is allowed to idle. This is not what we want. Do you agree? If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO, then I do not have the above problem. To be honest, with you the more I look and test the code, the more confused I am by the definition of the CLKDM_CAN_HWSUP ... #define CLKDM_CAN_HWSUP (CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO) When I look at where these flags are used, I see that CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ... CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active Are the above the correct definitions? Not quite. These flags describe the capabilities as defined in CLKTRCTRL field of the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL) CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled) CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP) Ok, so it that case it is wrong to set CAN_DISABLE_AUTO for the EMU CD. Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3 it's described as The automatic hardware-supervised mode is disabled Ah-ha. So this explains the naming! Thanks! What is confusing to me is that the OMAP4 TRM doesn't list the NO_SLEEP mode as supported by the EMU. It seems to me that if the IP supports HW_AUTO, it should be able to be enabled *and* disabled. Maybe Paul/Benoit can clarify. Yes, it definitely appears that EMU does not support NO_SLEEP according to the TRM. However, even if it did, this would not help in this case as we need to keep the CD in the SW_WKUP state while active. However, the problem with this is it breaks the current software model that is used to manage the CDs. It is not a good solution, but for this domain it would appear that we would need to have another flag, such as, CAN_ENABLE_AUTO_ON_INACTIVE :-( Let me know what you think. Cheers Jon -- To unsubscribe from this list: send the line
Re: oprofile and ARM A9 hardware counter
Jon Hunter jon-hun...@ti.com writes: Hi Will, On 04/26/2012 01:07 PM, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote: Part of the problem is that the clockdomain data for the emu_sys clockdomain is wrong. Here's something to try to fix it. It might just be enough to get it to work. Hmm, doesn't seem to work but I do see the following in dmesg when I try to use perf: powerdomain: waited too long for powerdomain emu_pwrdm to complete transition which is new with your patch. Sorry to nag, but does anybody have a clue where to go from here? I can start digging in the OMAP PM code, but it's all new territory for me. I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list. Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. Cheers Jon From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001 From: Jon Hunter jon-hun...@ti.com Date: Fri, 4 May 2012 16:48:45 -0500 Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition to the enabled and disabled state. This means that as soon as we force a software wake-up on the clock domain, the clock domain will be allowed to idle and put back into the hardware auto state. For the EMU clock domain this is not what we want. We want to keep the clock domain in the software wakeup state while the clock domain is being used and put it back in to the hardware auto state when we have finished using the clock domain. Signed-off-by: Jon Hunter jon-hun...@ti.com With this patch, how is the clkdm ever idled? IIUC, your patch will get PMU interrupts working, but similarily to previous patches in this thread, it works because it *never* allows the EMU clkdm to idle. This is not a mergeable solution because it will not allow CORE retention (and thus full-chip retention.) What we need is a solution that allows the clkdm to idle, and then to be reinitialzed when it wakes up. Due to the way (I understand) resets in the debugss, allowing the clkdm to idle will cause a reset, so the PMU/CTI interrupts need to be reinitialzied after wakeup. Kevin P.S. Please note there is also already a different fix in mainline for the EMU clkdm data from Paul which adds the force wakeup flag and removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag, because the hardware is capable.) [1] Author: Paul Walmsley p...@pwsan.com 2012-04-04 07:25:25 Committer: Paul Walmsley p...@pwsan.com 2012-04-04 07:25:25 Parent: c16fa4f2ad19908a47c63d8fa436a1178438c7e7 (Linux 3.3) Branches: many (164) Follows: v3.4-rc1 Precedes: omap-fixes-a-for-3.4rc, omap-fixes-a2-for-3.4rc ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm CLKTRCTRL data According to the 4430 ES2.0 TRM vX Table 3-744 CM_EMU_CLKSTCTRL, the emu_sys clockdomain data in mainline is incorrect. The emu_sys clockdomain does not support the DISABLE_AUTO state, and instead it supports the FORCE_WAKEUP state. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Benoît Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Ming Lei ming@canonical.com Cc: Will Deacon will.dea...@arm.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Tue, May 1, 2012 at 6:25 AM, Kevin Hilman khil...@ti.com wrote: Unfortunately, digging in the code isn't going to help much. We've been trying to get our heads around some undocumented reset behavior for the various debug IPs in OMAP. After a little digging and clarification from HW designers, it appears that if we allow the EMU clockdomain to idle, a full reset of the debug IPs is done. That means there are two solutions to this problem: 1) don't ever alow EMU clockdomain to idle. 2) modify CTI driver to re-init for every use. Obviously (1) is the easiet, and hacks for that have already been posted, but that has pretty significant impacts on power savings. (2) is the right solution to merge upstream, but needs writing. For (2), using runtime PM methods in the driver would be the simplest here since the -runtime_resume method will be called every time the device is about to be used. The previous patch has supported runtime pm on omap4 pmu[1], but still didn't fix the problem. Could you comment on the patch and point out the proper way to support pmu runtime for fixing the problem? [1], http://marc.info/?l=linux-arm-kernelm=131946777028358w=2 Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Kevin, On 05/07/2012 12:15 PM, Kevin Hilman wrote: Jon Hunter jon-hun...@ti.com writes: Hi Will, On 04/26/2012 01:07 PM, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote: Part of the problem is that the clockdomain data for the emu_sys clockdomain is wrong. Here's something to try to fix it. It might just be enough to get it to work. Hmm, doesn't seem to work but I do see the following in dmesg when I try to use perf: powerdomain: waited too long for powerdomain emu_pwrdm to complete transition which is new with your patch. Sorry to nag, but does anybody have a clue where to go from here? I can start digging in the OMAP PM code, but it's all new territory for me. I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list. Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. Cheers Jon From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001 From: Jon Hunter jon-hun...@ti.com Date: Fri, 4 May 2012 16:48:45 -0500 Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition to the enabled and disabled state. This means that as soon as we force a software wake-up on the clock domain, the clock domain will be allowed to idle and put back into the hardware auto state. For the EMU clock domain this is not what we want. We want to keep the clock domain in the software wakeup state while the clock domain is being used and put it back in to the hardware auto state when we have finished using the clock domain. Signed-off-by: Jon Hunter jon-hun...@ti.com With this patch, how is the clkdm ever idled? It does not! Sorry, I was so engrossed with figuring out why the EMU clkdm was being idled as soon as it was enabled, I forgot to check if is ever disabled once we terminated perf :-( IIUC, your patch will get PMU interrupts working, but similarily to previous patches in this thread, it works because it *never* allows the EMU clkdm to idle. This is not a mergeable solution because it will not allow CORE retention (and thus full-chip retention.) Right! What we need is a solution that allows the clkdm to idle, and then to be reinitialzed when it wakes up. Due to the way (I understand) resets in the debugss, allowing the clkdm to idle will cause a reset, so the PMU/CTI interrupts need to be reinitialzied after wakeup. Yes exactly I see that now. I have prototyped the 3 patches and this is working AND the EMU clkdm does go back to idle. I can send out to the list for review. Kevin P.S. Please note there is also already a different fix in mainline for the EMU clkdm data from Paul which adds the force wakeup flag and removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag, because the hardware is capable.) Hmmm ... yes saw this, and you will have to excuse me as I don't fully follow the logic here. In fact, I am thinking we want the opposite ;-) From looking, into this it seems to me that when PMU is running we want the EMU clock domain in software-wakeup state and when PMU is not running we want in the hardware auto state. By keeping the ENABLE_AUTO flag set, as soon as we enable the clock domain it is put right back into the HW_AUTO state and hence PMU is not working (see _enable() function in arch/arm/mach-omap2/omap_hwmod.c) So really what I think we want is to remove the ENABLE_AUTO flag to keep the clock domain in software wake-up and use the DISABLE_AUTO flag to put the clock domain back in HW_AUTO (note this requires a patch to perform this 2nd part). Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Jon Hunter jon-hun...@ti.com writes: Hi Kevin, On 05/07/2012 12:15 PM, Kevin Hilman wrote: Jon Hunter jon-hun...@ti.com writes: Hi Will, On 04/26/2012 01:07 PM, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote: Part of the problem is that the clockdomain data for the emu_sys clockdomain is wrong. Here's something to try to fix it. It might just be enough to get it to work. Hmm, doesn't seem to work but I do see the following in dmesg when I try to use perf: powerdomain: waited too long for powerdomain emu_pwrdm to complete transition which is new with your patch. Sorry to nag, but does anybody have a clue where to go from here? I can start digging in the OMAP PM code, but it's all new territory for me. I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list. Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. Cheers Jon From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001 From: Jon Hunter jon-hun...@ti.com Date: Fri, 4 May 2012 16:48:45 -0500 Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition to the enabled and disabled state. This means that as soon as we force a software wake-up on the clock domain, the clock domain will be allowed to idle and put back into the hardware auto state. For the EMU clock domain this is not what we want. We want to keep the clock domain in the software wakeup state while the clock domain is being used and put it back in to the hardware auto state when we have finished using the clock domain. Signed-off-by: Jon Hunter jon-hun...@ti.com With this patch, how is the clkdm ever idled? It does not! Sorry, I was so engrossed with figuring out why the EMU clkdm was being idled as soon as it was enabled, I forgot to check if is ever disabled once we terminated perf :-( IIUC, your patch will get PMU interrupts working, but similarily to previous patches in this thread, it works because it *never* allows the EMU clkdm to idle. This is not a mergeable solution because it will not allow CORE retention (and thus full-chip retention.) Right! What we need is a solution that allows the clkdm to idle, and then to be reinitialzed when it wakes up. Due to the way (I understand) resets in the debugss, allowing the clkdm to idle will cause a reset, so the PMU/CTI interrupts need to be reinitialzied after wakeup. Yes exactly I see that now. I have prototyped the 3 patches and this is working AND the EMU clkdm does go back to idle. I can send out to the list for review. Perfect, thanks. Kevin P.S. Please note there is also already a different fix in mainline for the EMU clkdm data from Paul which adds the force wakeup flag and removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag, because the hardware is capable.) Hmmm ... yes saw this, and you will have to excuse me as I don't fully follow the logic here. In fact, I am thinking we want the opposite ;-) From looking, into this it seems to me that when PMU is running we want the EMU clock domain in software-wakeup state and when PMU is not running we want in the hardware auto state. So far, I'm with you. By keeping the ENABLE_AUTO flag set, as soon as we enable the clock domain it is put right back into the HW_AUTO state This is only because it was in the HWSUP state when _enable was called. If clkdm_deny_idle() is used, that behavior will change. and hence PMU is not working (see _enable() function in arch/arm/mach-omap2/omap_hwmod.c) So really what I think we want is to remove the ENABLE_AUTO flag to keep the clock domain in software wake-up and use the DISABLE_AUTO flag to put the clock domain back in HW_AUTO (note this requires a patch to perform this 2nd part). Well, Paul will have to comment here for the final word, but IIUC, the hwmod flags are supposed to indicate only what the HW is capable of. If we want to change the runtime behavior, we nee to use (or add) APIs to change the beahvior. In this case, clkdm_allow_idle(), clkdm_deny_idle() are probably what is needed here. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Will,
On 04/26/2012 01:07 PM, Will Deacon wrote:
On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
Part of the problem is that the clockdomain data for the emu_sys
clockdomain is wrong. Here's something to try to fix it. It might just
be enough to get it to work.
Hmm, doesn't seem to work but I do see the following in dmesg when I try to
use perf:
powerdomain: waited too long for powerdomain emu_pwrdm to complete
transition
which is new with your patch.
Sorry to nag, but does anybody have a clue where to go from here? I can
start digging in the OMAP PM code, but it's all new territory for me.
I did a little playing around with this today and I think that I have figured
out why this was not working (see below). Please can you try the following
patch? I tried this on top of your series for perf/omap4.
Paul, FYI. If this works for Will then I can re-base on top of the latest
linux-omap and submit to the mailing list.
Also, the above error about the emu_pwrdm is odd too. I noticed that the
emu_pwrdm is always in the transitioning state. And when I say always, I mean
that even if I check the power domain state while u-boot is running it is in
the transitioning state. So even before the kernel starts.
Cheers
Jon
From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Fri, 4 May 2012 16:48:45 -0500
Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM
The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition
to the enabled and disabled state. This means that as soon as we force a
software wake-up on the clock domain, the clock domain will be allowed to idle
and put back into the hardware auto state. For the EMU clock domain this is not
what we want. We want to keep the clock domain in the software wakeup state
while the clock domain is being used and put it back in to the hardware auto
state when we have finished using the clock domain.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/clockdomains44xx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..dd2cd96 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags= CLKDM_CAN_HWSUP,
+ .flags= CLKDM_CAN_FORCE_WAKEUP | CLKDM_CAN_DISABLE_AUTO,
};
static struct clockdomain l3_dma_44xx_clkdm = {
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Will, Will Deacon will.dea...@arm.com writes: On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote: Part of the problem is that the clockdomain data for the emu_sys clockdomain is wrong. Here's something to try to fix it. It might just be enough to get it to work. Hmm, doesn't seem to work but I do see the following in dmesg when I try to use perf: powerdomain: waited too long for powerdomain emu_pwrdm to complete transition which is new with your patch. Sorry to nag, but does anybody have a clue where to go from here? I can start digging in the OMAP PM code, but it's all new territory for me. Unfortunately, digging in the code isn't going to help much. We've been trying to get our heads around some undocumented reset behavior for the various debug IPs in OMAP. After a little digging and clarification from HW designers, it appears that if we allow the EMU clockdomain to idle, a full reset of the debug IPs is done. That means there are two solutions to this problem: 1) don't ever alow EMU clockdomain to idle. 2) modify CTI driver to re-init for every use. Obviously (1) is the easiet, and hacks for that have already been posted, but that has pretty significant impacts on power savings. (2) is the right solution to merge upstream, but needs writing. For (2), using runtime PM methods in the driver would be the simplest here since the -runtime_resume method will be called every time the device is about to be used. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote: Part of the problem is that the clockdomain data for the emu_sys clockdomain is wrong. Here's something to try to fix it. It might just be enough to get it to work. Hmm, doesn't seem to work but I do see the following in dmesg when I try to use perf: powerdomain: waited too long for powerdomain emu_pwrdm to complete transition which is new with your patch. Sorry to nag, but does anybody have a clue where to go from here? I can start digging in the OMAP PM code, but it's all new territory for me. Cheers, Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Paul, On Wed, Apr 04, 2012 at 01:00:53AM +0100, Paul Walmsley wrote: On Tue, 3 Apr 2012, Will Deacon wrote: I'll take JTAG for a whirl to see where we are. If anything looks wrong in my dmesg, please shout (there are plenty of things in there that look like they've gone awry). Might be worth booting with initcall_debug on the kernel command line. That will probably be easier than dealing with JTAG. JTAG is unusable anyway because it requires a new MLO, which makes the problem disappear. Using initcall_debug I tracked the hang down to cti_unlock: val = __raw_readl(base + LOCKSTATUS); causes the board to die, presumably because CoreSight isn't in a fit state to be poked. Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote: Part of the problem is that the clockdomain data for the emu_sys clockdomain is wrong. Here's something to try to fix it. It might just be enough to get it to work. Hmm, doesn't seem to work but I do see the following in dmesg when I try to use perf: powerdomain: waited too long for powerdomain emu_pwrdm to complete transition which is new with your patch. Cheers, Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Santosh,
On Wed, Jan 18, 2012 at 12:33:23PM +, Shilimkar, Santosh wrote:
On Wed, Jan 18, 2012 at 1:24 PM, Ming Lei ming@canonical.com wrote:
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..41d2260 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_SWSUP,
};
NAK.
You don't need this patch. What you saw on CAMERA was indeed
a known bug but emulation domain has no such issues.
So the accesses to emulation register should continue to work
with the clock-domain being kept under hardware supervision.
But why can this patch make omap4 pmu work? Without the patch,
there are no CTI interrupts generated for pmu irq.
Interesting. For me debugger works which also relies on Emulation domain.
Need to see why CTI is behaving like this.
Did you ever get to the bottom of this? This change really is required in
order to generate PMU interrupts with the CTI and I don't know of any
alternative to the above.
Any suggestions?
Will
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Tue, Apr 3, 2012 at 2:55 PM, Will Deacon will.dea...@arm.com wrote:
Santosh,
On Wed, Jan 18, 2012 at 12:33:23PM +, Shilimkar, Santosh wrote:
On Wed, Jan 18, 2012 at 1:24 PM, Ming Lei ming@canonical.com wrote:
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..41d2260 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_SWSUP,
};
NAK.
You don't need this patch. What you saw on CAMERA was indeed
a known bug but emulation domain has no such issues.
So the accesses to emulation register should continue to work
with the clock-domain being kept under hardware supervision.
But why can this patch make omap4 pmu work? Without the patch,
there are no CTI interrupts generated for pmu irq.
Interesting. For me debugger works which also relies on Emulation domain.
Need to see why CTI is behaving like this.
Did you ever get to the bottom of this? This change really is required in
order to generate PMU interrupts with the CTI and I don't know of any
alternative to the above.
Any suggestions?
Sorry I lost track of this one. There is one relevant patch in Kevin's queue
for 3.4/fixes. [1] which I generated for perf time stamp issue.
Can you try that patch and see if it helps the CTI issue as well ? There
is an outside chance that it might help. If it doesn't, we should commit
Ming Lei patch.
Regards
Santosh
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/089679.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon will.dea...@arm.com wrote: On Tue, Apr 03, 2012 at 10:42:30AM +0100, Shilimkar, Santosh wrote: On Tue, Apr 3, 2012 at 2:55 PM, Will Deacon will.dea...@arm.com wrote: Did you ever get to the bottom of this? This change really is required in order to generate PMU interrupts with the CTI and I don't know of any alternative to the above. Any suggestions? Sorry I lost track of this one. There is one relevant patch in Kevin's queue for 3.4/fixes. [1] which I generated for perf time stamp issue. Thanks, I'll take a look. Can you try that patch and see if it helps the CTI issue as well ? There is an outside chance that it might help. If it doesn't, we should commit Ming Lei patch. It seems that they're both needed to get reliable PMU operation. Without the CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch below ([1]), it seems that we don't generate enough. So it looks like we need them both. I see. Can you please confirm if it is still the case with [1]. If yes then am nou sure how to proceed. because permanently setting EMU CD to CLKDM_CAN_SWSUP will break PM. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/089679.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Tue, Apr 03, 2012 at 11:01:53AM +0100, Shilimkar, Santosh wrote: On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon will.dea...@arm.com wrote: It seems that they're both needed to get reliable PMU operation. Without the CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch below ([1]), it seems that we don't generate enough. So it looks like we need them both. I see. Can you please confirm if it is still the case with [1]. Right, ignore my previous comment, I was using a vanilla 3.3 kernel without realising and therefore what I thought were PMU/CTI interrupts were actually just from a timer. Sorry for the confusion. So I've gone back to basics. Here is a branch containing what I believe should be all the patches required for the OMAP4 PMU: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4 I've omitted the SWSUSP patch since you say it breaks pm, which is clearly not acceptable. The problem is, trying to boot this on my pandaboard results in a hang (see dmesg below). Even worse, the problem isn't easily bisectable since rebuilding a working image can give you something that no longer boots and I haven't found a reliable way to cause the lockup. I'll take JTAG for a whirl to see where we are. If anything looks wrong in my dmesg, please shout (there are plenty of things in there that look like they've gone awry). Will Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.3.0-5-gcd122ab (will@mudshark) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3) ) #1 SMP Tue Apr 3 13:19:29 BST 2012 [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: OMAP4 Panda board [0.00] bootconsole [earlycon0] enabled [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] OMAP4430 ES2.1 [0.00] PERCPU: Embedded 8 pages/cpu @c1025000 s11072 r8192 d13504 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129792 [0.00] Kernel command line: console=ttyO2,115200 root=/dev/nfs nfsroot=10.1.79.58:/exports/linaro-11.11,tcp rw earlyprintk ip=dhcp [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 511MB = 511MB total [0.00] Memory: 506272k/506272k available, 18016k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xe080 - 0xff00 ( 488 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc05ebf68 (6032 kB) [0.00] .init : 0xc05ec000 - 0xc0639b40 ( 311 kB) [0.00] .data : 0xc063a000 - 0xc06c6d50 ( 564 kB) [0.00].bss : 0xc06c6d74 - 0xc0c1cb5c (5464 kB) [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:474 [0.00] omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck. [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.056579] Calibrating delay loop... 2007.19 BogoMIPS (lpj=7839744) [0.129791] pid_max: default: 32768 minimum: 301 [0.135192] Security Framework initialized [0.139678] Mount-cache hash table entries: 512 [0.147979] CPU: Testing write buffer coherency: ok [0.153961] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [0.160278] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available [0.168853] Setting up static identity map for 0x8043ce60 - 0x8043ced0 [0.175689] L310 cache controller enabled [0.179931] l2x0: 16 ways, CACHE_ID 0x41c4, AUX_CTRL 0x7e47, Cache size: 1048576 B [0.190856] CPU1: Booted secondary processor [0.254028] CPU1: thread -1, cpu 1, socket 0, mpidr 8001 [0.254058] CPU1: Unknown IPI message
Re: oprofile and ARM A9 hardware counter
On Tue, Apr 3, 2012 at 6:04 PM, Will Deacon will.dea...@arm.com wrote: On Tue, Apr 03, 2012 at 11:01:53AM +0100, Shilimkar, Santosh wrote: On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon will.dea...@arm.com wrote: It seems that they're both needed to get reliable PMU operation. Without the CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch below ([1]), it seems that we don't generate enough. So it looks like we need them both. I see. Can you please confirm if it is still the case with [1]. Right, ignore my previous comment, I was using a vanilla 3.3 kernel without realising and therefore what I thought were PMU/CTI interrupts were actually just from a timer. Sorry for the confusion. So I've gone back to basics. Here is a branch containing what I believe should be all the patches required for the OMAP4 PMU: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4 I've omitted the SWSUSP patch since you say it breaks pm, which is clearly not acceptable. The problem is, trying to boot this on my pandaboard results in a hang (see dmesg below). Even worse, the problem isn't easily bisectable since rebuilding a working image can give you something that no longer boots and I haven't found a reliable way to cause the lockup. I'll take JTAG for a whirl to see where we are. If anything looks wrong in my dmesg, please shout (there are plenty of things in there that look like they've gone awry). I don't see anything abnormal in below boot log. Not sure why it hands around there. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Will, Will Deacon will.dea...@arm.com writes: On Tue, Apr 03, 2012 at 11:01:53AM +0100, Shilimkar, Santosh wrote: On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon will.dea...@arm.com wrote: It seems that they're both needed to get reliable PMU operation. Without the CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch below ([1]), it seems that we don't generate enough. So it looks like we need them both. I see. Can you please confirm if it is still the case with [1]. Right, ignore my previous comment, I was using a vanilla 3.3 kernel without realising and therefore what I thought were PMU/CTI interrupts were actually just from a timer. Sorry for the confusion. So I've gone back to basics. Here is a branch containing what I believe should be all the patches required for the OMAP4 PMU: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4 I've omitted the SWSUSP patch since you say it breaks pm, which is clearly not acceptable. The problem is, trying to boot this on my pandaboard results in a hang (see dmesg below). Even worse, the problem isn't easily bisectable since rebuilding a working image can give you something that no longer boots and I haven't found a reliable way to cause the lockup. I'll take JTAG for a whirl to see where we are. If anything looks wrong in my dmesg, please shout (there are plenty of things in there that look like they've gone awry). Not sure why it hangs for you, but it worked for me both with your branch on v3.3 and merging with v3.4-rc1[1] Below is a Kconfig snippet[2] which I append to my .config after building omap2plus_defconfig in order to build a perf/trace/PMU enabled kernel for my Panda. Kevin [1] # perf stat sleep 1 Performance counter stats for 'sleep 1': 9.582520 task-clock#0.009 CPUs utilized 1 context-switches #0.104 K/sec 0 CPU-migrations#0.000 K/sec 147 page-faults #0.015 M/sec 5096283 cycles#0.532 GHz 607876 stalled-cycles-frontend # 11.93% frontend cycles idle 3285045 stalled-cycles-backend# 64.46% backend cycles idle 2722485 instructions #0.53 insns per cycle #1.21 stalled cycles per insn 259247 branches # 27.054 M/sec 84274 branch-misses # 32.51% of all branches 1.015919088 seconds time elapsed [2] CONFIG_ARCH_OMAP2=n CONFIG_ARCH_OMAP3=n # need to disable OMAP3 for CPU_HAS_PMU support, needed for perf on OMAP4 CONFIG_USB_EHCI_HCD=y CONFIG_USB_NET_SMSC95XX=y CONFIG_PROFILING=y CONFIG_HW_PERF_EVENTS=y CONFIG_PERF_EVENTS=y CONFIG_PERF_COUNTERS=y CONFIG_TRACEPOINTS=y CONFIG_TRACING=y CONFIG_GENERIC_TRACER=y CONFIG_FTRACE=y CONFIG_FUNCTION_TRACER=y CONFIG_ENABLE_DEFAULT_TRACERS=y CONFIG_STACK_TRACER=y CONFIG_SCHED_TRACER=y CONFIG_EVENT_POWER_TRACING_DEPRECATED=n -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Tue, Apr 03, 2012 at 03:27:52PM +0100, Kevin Hilman wrote: Hi Will, Hi Kevin, Will Deacon will.dea...@arm.com writes: The problem is, trying to boot this on my pandaboard results in a hang (see dmesg below). Even worse, the problem isn't easily bisectable since rebuilding a working image can give you something that no longer boots and I haven't found a reliable way to cause the lockup. I'll take JTAG for a whirl to see where we are. If anything looks wrong in my dmesg, please shout (there are plenty of things in there that look like they've gone awry). Not sure why it hangs for you, but it worked for me both with your branch on v3.3 and merging with v3.4-rc1[1] Thanks for testing that. It turns out that updating my x-loader (it was pretty ancient) fixed the boot hang, though I'm not sure I want to know why! # perf stat sleep 1 Performance counter stats for 'sleep 1': 9.582520 task-clock#0.009 CPUs utilized 1 context-switches #0.104 K/sec 0 CPU-migrations#0.000 K/sec 147 page-faults #0.015 M/sec 5096283 cycles#0.532 GHz 607876 stalled-cycles-frontend # 11.93% frontend cycles idle 3285045 stalled-cycles-backend# 64.46% backend cycles idle 2722485 instructions #0.53 insns per cycle #1.21 stalled cycles per insn 259247 branches # 27.054 M/sec 84274 branch-misses # 32.51% of all branches Right. Can you confirm whether the PMU/CTI interrupts fire for you please? Just run perf top and look at /proc/interrupts while it's running. You should see a couple of arm-pmu entries in there and hopefully numbers 0. For me, my earlier mis-diagnosis has turned out to be true and I can only see PMU interrupts if I apply the SWSUSP patch, which Santosh says will break pm. Cheers, Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Will Deacon will.dea...@arm.com writes:
[...]
Right. Can you confirm whether the PMU/CTI interrupts fire for you please?
Just run perf top and look at /proc/interrupts while it's running. You
should see a couple of arm-pmu entries in there and hopefully numbers 0.
Ah, I see now (I'm a perf newbie.)
Indeed, like you, I have to change the EMU clock domain to SWSUP[1] in
order to see any interrupts and see anything in perf top. This isn't
really a mergeable workaround, so I'll look into this a little closer
with Santosh to see what we can do once we fully understand the HW
problem.
Kevin
[1]
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..41d2260 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags= CLKDM_CAN_HWSUP,
+ .flags= CLKDM_CAN_SWSUP,
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi
On Tue, 3 Apr 2012, Kevin Hilman wrote:
Indeed, like you, I have to change the EMU clock domain to SWSUP[1] in
order to see any interrupts and see anything in perf top. This isn't
really a mergeable workaround, so I'll look into this a little closer
with Santosh to see what we can do once we fully understand the HW
problem.
Part of the problem is that the clockdomain data for the emu_sys
clockdomain is wrong. Here's something to try to fix it. It might just
be enough to get it to work.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Tue, 3 Apr 2012 17:13:48 -0600
Subject: [PATCH] ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm
CLKTRCTRL data
According to the 4430 ES2.0 TRM vX Table 3-744 CM_EMU_CLKSTCTRL,
the emu_sys clockdomain data in mainline is incorrect.
The emu_sys clockdomain does not support the DISABLE_AUTO state, and
instead it supports the FORCE_WAKEUP state.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Ming Lei ming@canonical.com
---
arch/arm/mach-omap2/clockdomains44xx_data.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..bd7ed13 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags= CLKDM_CAN_HWSUP,
+ .flags= CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_FORCE_WAKEUP,
};
static struct clockdomain l3_dma_44xx_clkdm = {
--
1.7.9.5
Re: oprofile and ARM A9 hardware counter
On Tue, 3 Apr 2012, Will Deacon wrote: I'll take JTAG for a whirl to see where we are. If anything looks wrong in my dmesg, please shout (there are plenty of things in there that look like they've gone awry). Might be worth booting with initcall_debug on the kernel command line. That will probably be easier than dealing with JTAG. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Wed, Apr 4, 2012 at 7:29 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
On Tue, 3 Apr 2012, Kevin Hilman wrote:
Indeed, like you, I have to change the EMU clock domain to SWSUP[1] in
order to see any interrupts and see anything in perf top. This isn't
really a mergeable workaround, so I'll look into this a little closer
with Santosh to see what we can do once we fully understand the HW
problem.
Part of the problem is that the clockdomain data for the emu_sys
clockdomain is wrong. Here's something to try to fix it. It might just
be enough to get it to work.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Tue, 3 Apr 2012 17:13:48 -0600
Subject: [PATCH] ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm
CLKTRCTRL data
According to the 4430 ES2.0 TRM vX Table 3-744 CM_EMU_CLKSTCTRL,
the emu_sys clockdomain data in mainline is incorrect.
The emu_sys clockdomain does not support the DISABLE_AUTO state, and
instead it supports the FORCE_WAKEUP state.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Ming Lei ming@canonical.com
---
arch/arm/mach-omap2/clockdomains44xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..bd7ed13 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_FORCE_WAKEUP,
I tested the patch just now, but unfortunately, the change still doesn't make
PMU to generate IRQs.
Mark the flags as CLKDM_CAN_SWSUP may work, but PMU will stop producing
IRQs after resuming from suspend.
Thanks
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Wed, Mar 07, 2012 at 02:49:46AM +, Ming Lei wrote: Hi Will, Hello, On Fri, Jan 27, 2012 at 11:54 PM, Will Deacon will.dea...@arm.com wrote: Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so you may miss samples if they occur during critical kernel sections (and if you look at a profile, spin_unlock_irqrestore will be quite high). Also looks no any irq handler functions can be observed at a profile even though they may be run at a very high frequency. So could we configure ARM PMU interrupt as FIQ to address the above issues? I thought about that in the past but the problem is finding hardware which allows this. It probably means that you need a second GIC which can route interrupts onto the FIQ line into the CPU. Given that FIQ is usually claimed for secure interrupts, there could also still be latency issues here. A better (read: highly invasive) way to fix this is using interrupt priorities at the distributor. You then have to hack the interrupt disabling code so that it disables interrupts below a certain priority if they occur during an IRQ-off section. The re-enabling code would then have to undo those decisions and allow the interrupts to be serviced. Pretty nasty stuff. Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Will, On Fri, Jan 27, 2012 at 11:54 PM, Will Deacon will.dea...@arm.com wrote: Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so you may miss samples if they occur during critical kernel sections (and if you look at a profile, spin_unlock_irqrestore will be quite high). Also looks no any irq handler functions can be observed at a profile even though they may be run at a very high frequency. So could we configure ARM PMU interrupt as FIQ to address the above issues? thanks -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi,
On Mon, Jan 30, 2012 at 1:36 AM, stephane eranian
eran...@googlemail.com wrote:
Hi,
Ok, so I did a few more tests and there is a serious issue when sampling
in frequency mode (the default). I noticed wrong number of samples, so
I investigated this some more and instrumented the perf_event kernel code.
I found some erratic timer ticks causing broken period adjustments.
In fact, the problem is visible using top.
I am running a noploop program on CPU0 and nothing else besides top.
The noploop program does: for(;;);. That is 100% user. On a 2-way
Sometimes it is not 100% user, for example irq/exception handling...
system otherwise idle, I expect top to return 50% user 50% idle.
Top with the commit:
top - 16:19:21 up 5 min, 1 user, load average: 0.23, 0.15, 0.07
Tasks: 70 total, 2 running, 68 sleeping, 0 stopped, 0 zombie
Cpu(s): 31.1%us, 2.0%sy, 0.0%ni, 66.2%id, 0.0%wa, 0.0%hi, 0.7%si, 0.0%st
That's WRONG
Did you reproduce the issue each time or just occasionally?
Looks no such issue on my board with 3.3-rc1 plus the 5 extra pmu/emu patches.
top - 00:59:15 up 7 min, 1 user, load average: 1.00, 0.73, 0.35
Tasks: 56 total, 2 running, 54 sleeping, 0 stopped, 0 zombie
Cpu(s): 42.6%us, 0.2%sy, 0.0%ni, 56.8%id, 0.0%wa, 0.0%hi, 0.4%si, 0.0%st
Mem: 1013560k total,50960k used, 962600k free, 6272k buffers
Swap:0k total,0k used,0k free,29036k cached
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
1355 root 20 0 1460 260 216 R 99 0.0 5:07.38 busy
532 root 20 0 000 S0 0.0 0:00.23 kworker/1:1
1356 root 20 0 2552 1120 916 R0 0.1 0:01.93 top
Mem: 940292k total, 74984k used, 865308k free, 8020k buffers
Swap: 524240k total, 0k used, 524240k free, 37420k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3770 eranian 20 0 644 160 128 R 99 0.0 0:14.21 noploop
3771 eranian 20 0 2184 1052 804 R 2 0.1 0:00.32 top
1 root 20 0 2564 1528 952 S 0 0.2 0:01.26 init
I removed that one liner patch from Ming. The one fiddling with the
clockdomains:
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_SWSUP,
The patch should not affect timer tick logic, and what the patch does is
just to revert the commit [1] wrt. emu clock domain.
When I rerun, the test, it now work:
top - 16:02:51 up 15 min, 1 user, load average: 1.02, 0.46, 0.21
Tasks: 70 total, 2 running, 68 sleeping, 0 stopped, 0 zombie
Cpu(s): 47.2%us, 1.0%sy, 0.0%ni, 50.8%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st
close enough (in it stabilize somehow around 49%
which is good)
Mem: 940292k total, 75288k used, 865004k free, 8004k buffers
Swap: 524240k total, 0k used, 524240k free, 37408k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3771 eranian 20 0 644 160 128 R 100 0.0 0:34.44 noploop
Although the patch fixes PMU interrupts, it breaks the timer tick logic
somehow.
The perf problem is related to timer tick.
I am hoping that the tradeoff is not:
PMU interrupts but broken timer ticks
vs.
No PMU interrupts but working timer ticks
[1], 3c50729b3fa1cd8ca1f347e6caf1081204cf1a7c
ARM: OMAP4: PM: Initialise all the clockdomains to supported states
thanks
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Ok, let me try again with 3.3.0-rc1, that was with 3.2.0.
The only thing that changed was that one line and it made
a big difference.
On Mon, Jan 30, 2012 at 10:40 AM, Ming Lei ming@canonical.com wrote:
Hi,
On Mon, Jan 30, 2012 at 1:36 AM, stephane eranian
eran...@googlemail.com wrote:
Hi,
Ok, so I did a few more tests and there is a serious issue when sampling
in frequency mode (the default). I noticed wrong number of samples, so
I investigated this some more and instrumented the perf_event kernel code.
I found some erratic timer ticks causing broken period adjustments.
In fact, the problem is visible using top.
I am running a noploop program on CPU0 and nothing else besides top.
The noploop program does: for(;;);. That is 100% user. On a 2-way
Sometimes it is not 100% user, for example irq/exception handling...
system otherwise idle, I expect top to return 50% user 50% idle.
Top with the commit:
top - 16:19:21 up 5 min, 1 user, load average: 0.23, 0.15, 0.07
Tasks: 70 total, 2 running, 68 sleeping, 0 stopped, 0 zombie
Cpu(s): 31.1%us, 2.0%sy, 0.0%ni, 66.2%id, 0.0%wa, 0.0%hi, 0.7%si,
0.0%st
That's WRONG
Did you reproduce the issue each time or just occasionally?
Looks no such issue on my board with 3.3-rc1 plus the 5 extra pmu/emu patches.
top - 00:59:15 up 7 min, 1 user, load average: 1.00, 0.73, 0.35
Tasks: 56 total, 2 running, 54 sleeping, 0 stopped, 0 zombie
Cpu(s): 42.6%us, 0.2%sy, 0.0%ni, 56.8%id, 0.0%wa, 0.0%hi, 0.4%si, 0.0%st
Mem: 1013560k total, 50960k used, 962600k free, 6272k buffers
Swap: 0k total, 0k used, 0k free, 29036k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1355 root 20 0 1460 260 216 R 99 0.0 5:07.38 busy
532 root 20 0 0 0 0 S 0 0.0 0:00.23 kworker/1:1
1356 root 20 0 2552 1120 916 R 0 0.1 0:01.93 top
Mem: 940292k total, 74984k used, 865308k free, 8020k buffers
Swap: 524240k total, 0k used, 524240k free, 37420k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3770 eranian 20 0 644 160 128 R 99 0.0 0:14.21 noploop
3771 eranian 20 0 2184 1052 804 R 2 0.1 0:00.32 top
1 root 20 0 2564 1528 952 S 0 0.2 0:01.26 init
I removed that one liner patch from Ming. The one fiddling with the
clockdomains:
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_SWSUP,
The patch should not affect timer tick logic, and what the patch does is
just to revert the commit [1] wrt. emu clock domain.
When I rerun, the test, it now work:
top - 16:02:51 up 15 min, 1 user, load average: 1.02, 0.46, 0.21
Tasks: 70 total, 2 running, 68 sleeping, 0 stopped, 0 zombie
Cpu(s): 47.2%us, 1.0%sy, 0.0%ni, 50.8%id, 0.0%wa, 0.0%hi, 1.0%si,
0.0%st
close enough (in it stabilize somehow around 49%
which is good)
Mem: 940292k total, 75288k used, 865004k free, 8004k buffers
Swap: 524240k total, 0k used, 524240k free, 37408k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3771 eranian 20 0 644 160 128 R 100 0.0 0:34.44 noploop
Although the patch fixes PMU interrupts, it breaks the timer tick logic
somehow.
The perf problem is related to timer tick.
I am hoping that the tradeoff is not:
PMU interrupts but broken timer ticks
vs.
No PMU interrupts but working timer ticks
[1], 3c50729b3fa1cd8ca1f347e6caf1081204cf1a7c
ARM: OMAP4: PM: Initialise all the clockdomains to supported states
thanks
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Same results for me with 3.3.0-rc1 + 5 patches.
top - 14:42:34 up 8 min, 1 user, load average: 0.70, 0.29, 0.15
Tasks: 75 total, 2 running, 73 sleeping, 0 stopped, 0 zombie
Cpu(s): 32.9%us, 1.3%sy, 0.0%ni, 65.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 940232k total, 118520k used, 821712k free, 8080k buffers
Swap: 524240k total, 0k used, 524240k free, 79432k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3868 eranian 20 0 644 160 128 R 99 0.0 0:53.34 noploop
3870 eranian 20 0 2284 1060 804 R 3 0.1 0:00.63 top
1 root 20 0 2564 1532 952 S 0 0.2 0:01.26 init
I am connecting to the board via ssh.
But the results don't look correct to me.
On Mon, Jan 30, 2012 at 11:24 AM, stephane eranian
eran...@googlemail.com wrote:
Ok, let me try again with 3.3.0-rc1, that was with 3.2.0.
The only thing that changed was that one line and it made
a big difference.
On Mon, Jan 30, 2012 at 10:40 AM, Ming Lei ming@canonical.com wrote:
Hi,
On Mon, Jan 30, 2012 at 1:36 AM, stephane eranian
eran...@googlemail.com wrote:
Hi,
Ok, so I did a few more tests and there is a serious issue when sampling
in frequency mode (the default). I noticed wrong number of samples, so
I investigated this some more and instrumented the perf_event kernel code.
I found some erratic timer ticks causing broken period adjustments.
In fact, the problem is visible using top.
I am running a noploop program on CPU0 and nothing else besides top.
The noploop program does: for(;;);. That is 100% user. On a 2-way
Sometimes it is not 100% user, for example irq/exception handling...
system otherwise idle, I expect top to return 50% user 50% idle.
Top with the commit:
top - 16:19:21 up 5 min, 1 user, load average: 0.23, 0.15, 0.07
Tasks: 70 total, 2 running, 68 sleeping, 0 stopped, 0 zombie
Cpu(s): 31.1%us, 2.0%sy, 0.0%ni, 66.2%id, 0.0%wa, 0.0%hi, 0.7%si,
0.0%st
That's WRONG
Did you reproduce the issue each time or just occasionally?
Looks no such issue on my board with 3.3-rc1 plus the 5 extra pmu/emu
patches.
top - 00:59:15 up 7 min, 1 user, load average: 1.00, 0.73, 0.35
Tasks: 56 total, 2 running, 54 sleeping, 0 stopped, 0 zombie
Cpu(s): 42.6%us, 0.2%sy, 0.0%ni, 56.8%id, 0.0%wa, 0.0%hi, 0.4%si,
0.0%st
Mem: 1013560k total, 50960k used, 962600k free, 6272k buffers
Swap: 0k total, 0k used, 0k free, 29036k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1355 root 20 0 1460 260 216 R 99 0.0 5:07.38 busy
532 root 20 0 0 0 0 S 0 0.0 0:00.23 kworker/1:1
1356 root 20 0 2552 1120 916 R 0 0.1 0:01.93 top
Mem: 940292k total, 74984k used, 865308k free, 8020k buffers
Swap: 524240k total, 0k used, 524240k free, 37420k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3770 eranian 20 0 644 160 128 R 99 0.0 0:14.21 noploop
3771 eranian 20 0 2184 1052 804 R 2 0.1 0:00.32 top
1 root 20 0 2564 1528 952 S 0 0.2 0:01.26 init
I removed that one liner patch from Ming. The one fiddling with the
clockdomains:
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_SWSUP,
The patch should not affect timer tick logic, and what the patch does is
just to revert the commit [1] wrt. emu clock domain.
When I rerun, the test, it now work:
top - 16:02:51 up 15 min, 1 user, load average: 1.02, 0.46, 0.21
Tasks: 70 total, 2 running, 68 sleeping, 0 stopped, 0 zombie
Cpu(s): 47.2%us, 1.0%sy, 0.0%ni, 50.8%id, 0.0%wa, 0.0%hi, 1.0%si,
0.0%st
close enough (in it stabilize somehow around 49%
which is good)
Mem: 940292k total, 75288k used, 865004k free, 8004k buffers
Swap: 524240k total, 0k used, 524240k free, 37408k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3771 eranian 20 0 644 160 128 R 100 0.0 0:34.44 noploop
Although the patch fixes PMU interrupts, it breaks the timer tick logic
somehow.
The perf problem is related to timer tick.
I am hoping that the tradeoff is not:
PMU interrupts but broken timer ticks
vs.
No PMU interrupts but working timer ticks
[1], 3c50729b3fa1cd8ca1f347e6caf1081204cf1a7c
ARM: OMAP4: PM: Initialise all the clockdomains to supported states
thanks
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
Re: oprofile and ARM A9 hardware counter
On Mon, Jan 30, 2012 at 9:43 PM, stephane eranian eran...@googlemail.com wrote: Same results for me with 3.3.0-rc1 + 5 patches. In fact, I think the only effect of the patch is to enable pmu interrupt handling, which may cause so much difference? Also maybe you should put 'noploop' to run on CPU1 and you may observe a more accurate result of 'top'. On ARM, almost handling of all IRQs from gic is run on CPU0 at default, which may cause your issue. top - 14:42:34 up 8 min, 1 user, load average: 0.70, 0.29, 0.15 Tasks: 75 total, 2 running, 73 sleeping, 0 stopped, 0 zombie Cpu(s): 32.9%us, 1.3%sy, 0.0%ni, 65.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 940232k total, 118520k used, 821712k free, 8080k buffers Swap: 524240k total, 0k used, 524240k free, 79432k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3868 eranian 20 0 644 160 128 R 99 0.0 0:53.34 noploop 3870 eranian 20 0 2284 1060 804 R 3 0.1 0:00.63 top 1 root 20 0 2564 1532 952 S 0 0.2 0:01.26 init I am connecting to the board via ssh. But the results don't look correct to me. thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Same result for me on CPU1: top - 16:20:24 up 1:45, 1 user, load average: 0.29, 0.08, 0.07 Tasks: 70 total, 2 running, 68 sleeping, 0 stopped, 0 zombie Cpu(s): 30.7%us, 2.7%sy, 0.0%ni, 66.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem:940232k total, 228984k used, 711248k free,82244k buffers Swap: 524240k total,0k used, 524240k free,91400k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND 3968 eranian 20 0 644 160 128 R 100 0.0 0:21.98 1 noploop 3969 eranian 20 0 2184 1056 804 R3 0.1 0:00.53 0 top 82 root 20 0 000 S1 0.0 0:01.35 0 kworker/0:1 With 3.3.0-rc1, if I revert the clockdomain patch, I get the same result. So it must be coming from somewhere else, as you suggested. If the processor was spending time processing interrupts, then this would be accounted for in as sys time. But that's not what I observe here. It's either idle or user. That line, leads me to believe that the processor can only run my program for 30% of the time. The rest is spent idling even though my program is non-blocking. How could that be possible? Power-saving? On Mon, Jan 30, 2012 at 3:49 PM, Ming Lei ming@canonical.com wrote: On Mon, Jan 30, 2012 at 9:43 PM, stephane eranian eran...@googlemail.com wrote: Same results for me with 3.3.0-rc1 + 5 patches. In fact, I think the only effect of the patch is to enable pmu interrupt handling, which may cause so much difference? Also maybe you should put 'noploop' to run on CPU1 and you may observe a more accurate result of 'top'. On ARM, almost handling of all IRQs from gic is run on CPU0 at default, which may cause your issue. top - 14:42:34 up 8 min, 1 user, load average: 0.70, 0.29, 0.15 Tasks: 75 total, 2 running, 73 sleeping, 0 stopped, 0 zombie Cpu(s): 32.9%us, 1.3%sy, 0.0%ni, 65.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 940232k total, 118520k used, 821712k free, 8080k buffers Swap: 524240k total, 0k used, 524240k free, 79432k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3868 eranian 20 0 644 160 128 R 99 0.0 0:53.34 noploop 3870 eranian 20 0 2284 1060 804 R 3 0.1 0:00.63 top 1 root 20 0 2564 1532 952 S 0 0.2 0:01.26 init I am connecting to the board via ssh. But the results don't look correct to me. thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
stephane eranian eran...@googlemail.com writes: Same result for me on CPU1: top - 16:20:24 up 1:45, 1 user, load average: 0.29, 0.08, 0.07 Tasks: 70 total, 2 running, 68 sleeping, 0 stopped, 0 zombie Cpu(s): 30.7%us, 2.7%sy, 0.0%ni, 66.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem:940232k total, 228984k used, 711248k free,82244k buffers Swap: 524240k total,0k used, 524240k free,91400k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND 3968 eranian 20 0 644 160 128 R 100 0.0 0:21.98 1 noploop 3969 eranian 20 0 2184 1056 804 R3 0.1 0:00.53 0 top 82 root 20 0 000 S1 0.0 0:01.35 0 kworker/0:1 With 3.3.0-rc1, if I revert the clockdomain patch, I get the same result. So it must be coming from somewhere else, as you suggested. If the processor was spending time processing interrupts, then this would be accounted for in as sys time. But that's not what I observe here. It's either idle or user. That line, leads me to believe that the processor can only run my program for 30% of the time. The rest is spent idling even though my program is non-blocking. How could that be possible? Power-saving? In top, press 1 to see the statistics for the CPUs separately. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Mon, Jan 30, 2012 at 5:08 PM, Måns Rullgård m...@mansr.com wrote: stephane eranian eran...@googlemail.com writes: Same result for me on CPU1: top - 16:20:24 up 1:45, 1 user, load average: 0.29, 0.08, 0.07 Tasks: 70 total, 2 running, 68 sleeping, 0 stopped, 0 zombie Cpu(s): 30.7%us, 2.7%sy, 0.0%ni, 66.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 940232k total, 228984k used, 711248k free, 82244k buffers Swap: 524240k total, 0k used, 524240k free, 91400k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND 3968 eranian 20 0 644 160 128 R 100 0.0 0:21.98 1 noploop 3969 eranian 20 0 2184 1056 804 R 3 0.1 0:00.53 0 top 82 root 20 0 0 0 0 S 1 0.0 0:01.35 0 kworker/0:1 With 3.3.0-rc1, if I revert the clockdomain patch, I get the same result. So it must be coming from somewhere else, as you suggested. If the processor was spending time processing interrupts, then this would be accounted for in as sys time. But that's not what I observe here. It's either idle or user. That line, leads me to believe that the processor can only run my program for 30% of the time. The rest is spent idling even though my program is non-blocking. How could that be possible? Power-saving? In top, press 1 to see the statistics for the CPUs separately. Ok, when I pin my program to CPU1, and press 1 in top I get: asks: 69 total, 2 running, 67 sleeping, 0 stopped, 0 zombie Cpu0 : 0.9%us, 3.8%sy, 0.0%ni, 94.3%id, 0.0%wa, 0.0%hi, 0.9%si, 0.0%st Cpu1 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem:940232k total,75480k used, 864752k free, 8148k buffers Swap: 524240k total,0k used, 524240k free,37568k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 3788 eranian 20 0 644 160 128 R 100 0.0 0:47.93 noploop 3758 eranian 20 0 9900 1512 712 S2 0.2 0:01.17 sshd 3789 eranian 20 0 2184 1056 804 R2 0.1 0:01.22 top Which gives me the right answer. But in 'collapsed mode', press 1 again, the aggregate value is bogus. Could be wrong math in top. Ok, that was a false alarm then. Thanks for the help. Still need to investigate why the frequency mode does not yield the correct number of samples even with low frequency. $ taskset -c 1 perf record -e cycles -F 100 noploop 10 $ perf report -D | tail -20 Aggregated stats: TOTAL events:475 MMAP events: 11 COMM events: 2 EXIT events: 2 SAMPLE events:460 cycles stats: TOTAL events:475 MMAP events: 11 COMM events: 2 EXIT events: 2 SAMPLE events:460 460 samples is way too low. Should be 100x10 = 1000 samples or close to it. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Mon, Jan 30, 2012 at 05:15:53PM +, stephane eranian wrote: Still need to investigate why the frequency mode does not yield the correct number of samples even with low frequency. $ taskset -c 1 perf record -e cycles -F 100 noploop 10 $ perf report -D | tail -20 Aggregated stats: TOTAL events:475 MMAP events: 11 COMM events: 2 EXIT events: 2 SAMPLE events:460 cycles stats: TOTAL events:475 MMAP events: 11 COMM events: 2 EXIT events: 2 SAMPLE events:460 460 samples is way too low. Should be 100x10 = 1000 samples or close to it. Can you stick noploop.c somewhere (I'm lazy :) and I'll try it on one of my A9 boards? Thanks, Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Will,
There you go, no attachment, not sure the omap list
supports this.
There is something quite interesting to observe.
While I run perf record -e cycles -F 100 noploop 10, I watch
/proc/interrupts. The number of interrupts is way lower than
expected. Therefore the number of samples is way too low:
$ perf record -e cycles -F 100 noploop 10
$ perf report -D | tail -20
cycles stats:
TOTAL events:535
MMAP events: 11
COMM events: 2
EXIT events: 2
SAMPLE events:520
The delta in /proc/interrupts on CPU1 is 520 interrupts.
So looks like the frequency adjustment which is hooked off of the
timer tick is either not called at each timer tick, the timer ticks are
not at regular interval, or the math is wrong.
If I go with the fixed period mode:
$ perf stat -e cycles noploop 10
noploop for 10 seconds
Performance counter stats for 'noploop 10':
10079156960 cycles#0.000 GHz
10.004547117 seconds time elapsed
That means, if I want 100 samples/sec: = 10079156960/(10*100)=10079157
$ perf record -e cycles -c 10079157 noploop 10
$ perf report -D | tail -20
cycles stats:
TOTAL events: 1003
MMAP events: 11
COMM events: 2
EXIT events: 2
THROTTLE events: 1
UNTHROTTLE events: 1
SAMPLE events:986
Now, we're getting the right answer!
So with the right sampling period, everything works fine.
We need to elucidate what's going on in perf_event_task_tick().
I have tried with my throttling fix and it did not help. We are
not subject to throttling with such a low rate.
noploop.c:
#include sys/types.h
#include stdio.h
#include stdlib.h
#include signal.h
#include inttypes.h
#include unistd.h
void handler(int sig)
{
exit(0);
}
void
noploop(void)
{
for(;;);
}
int
main(int argc, char **argv)
{
unsigned int delay;
delay = argc 1 ? atoi(argv[1]) : 1;
signal(SIGALRM, handler);
printf(noploop for %d seconds\n, delay);
alarm(delay);
noploop();
return 0;
}
On Mon, Jan 30, 2012 at 6:24 PM, Will Deacon will.dea...@arm.com wrote:
On Mon, Jan 30, 2012 at 05:15:53PM +, stephane eranian wrote:
Still need to investigate why the frequency mode does
not yield the correct number of samples even with low frequency.
$ taskset -c 1 perf record -e cycles -F 100 noploop 10
$ perf report -D | tail -20
Aggregated stats:
TOTAL events: 475
MMAP events: 11
COMM events: 2
EXIT events: 2
SAMPLE events: 460
cycles stats:
TOTAL events: 475
MMAP events: 11
COMM events: 2
EXIT events: 2
SAMPLE events: 460
460 samples is way too low. Should be 100x10 = 1000 samples or close to it.
Can you stick noploop.c somewhere (I'm lazy :) and I'll try it on one of my
A9 boards?
Thanks,
Will
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Mon, Jan 30, 2012 at 05:45:19PM +, stephane eranian wrote: There you go, no attachment, not sure the omap list supports this. Cheers Stephane. There is something quite interesting to observe. While I run perf record -e cycles -F 100 noploop 10, I watch /proc/interrupts. The number of interrupts is way lower than expected. Therefore the number of samples is way too low: $ perf record -e cycles -F 100 noploop 10 $ perf report -D | tail -20 cycles stats: TOTAL events:535 MMAP events: 11 COMM events: 2 EXIT events: 2 SAMPLE events:520 The delta in /proc/interrupts on CPU1 is 520 interrupts. Yes, that is about half of what you'd expect. Running on my A9 platform (vexpress) I get: $ perf record -e cycles -F 100 noploop 10 $ perf report -D | tail -20 cycles stats: TOTAL events: 1007 MMAP events: 18 COMM events: 2 EXIT events: 2 SAMPLE events:985 So looks like the frequency adjustment which is hooked off of the timer tick is either not called at each timer tick, the timer ticks are not at regular interval, or the math is wrong. My hunch is that that the interval is probably varying, but I don't know much about OMAP4 and its clocks. If I go with the fixed period mode: $ perf stat -e cycles noploop 10 noploop for 10 seconds Performance counter stats for 'noploop 10': 10079156960 cycles#0.000 GHz 10.004547117 seconds time elapsed That means, if I want 100 samples/sec: = 10079156960/(10*100)=10079157 $ perf record -e cycles -c 10079157 noploop 10 $ perf report -D | tail -20 cycles stats: TOTAL events: 1003 MMAP events: 11 COMM events: 2 EXIT events: 2 THROTTLE events: 1 UNTHROTTLE events: 1 SAMPLE events:986 Now, we're getting the right answer! Just to confirm, for me: $ perf stat -e cycles ./noploop 10 noploop for 10 seconds Performance counter stats for './noploop 10': 4001163930 cycles#0.000 GHz 10.006534024 seconds time elapsed $ perf record -e cycles -c 4001163 ./noploop 10 $ perf report -D | tail -20 Aggregated stats: TOTAL events: 1020 MMAP events: 18 COMM events: 2 EXIT events: 2 SAMPLE events:998 cycles stats: TOTAL events: 1020 MMAP events: 18 COMM events: 2 EXIT events: 2 SAMPLE events:998 which is close enough :) We need to elucidate what's going on in perf_event_task_tick(). I have tried with my throttling fix and it did not help. We are not subject to throttling with such a low rate. Ok. I would start by looking at the clock ticks if I were you, since this seems to be alright on my board. Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Mon, Jan 30, 2012 at 8:14 PM, Will Deacon will.dea...@arm.com wrote: On Mon, Jan 30, 2012 at 05:45:19PM +, stephane eranian wrote: There you go, no attachment, not sure the omap list supports this. Cheers Stephane. There is something quite interesting to observe. While I run perf record -e cycles -F 100 noploop 10, I watch /proc/interrupts. The number of interrupts is way lower than expected. Therefore the number of samples is way too low: $ perf record -e cycles -F 100 noploop 10 $ perf report -D | tail -20 cycles stats: TOTAL events: 535 MMAP events: 11 COMM events: 2 EXIT events: 2 SAMPLE events: 520 The delta in /proc/interrupts on CPU1 is 520 interrupts. Yes, that is about half of what you'd expect. Running on my A9 platform (vexpress) I get: $ perf record -e cycles -F 100 noploop 10 $ perf report -D | tail -20 cycles stats: TOTAL events: 1007 MMAP events: 18 COMM events: 2 EXIT events: 2 SAMPLE events: 985 So looks like the frequency adjustment which is hooked off of the timer tick is either not called at each timer tick, the timer ticks are not at regular interval, or the math is wrong. My hunch is that that the interval is probably varying, but I don't know much about OMAP4 and its clocks. Glad you tested this. At least, it seems the generic perf_event code is allright. I agree with you, something is fishy with the clocks. Just out of curiosity, what is the HZ value for your board? On my Panda it's 128Hz. If I go with the fixed period mode: $ perf stat -e cycles noploop 10 noploop for 10 seconds Performance counter stats for 'noploop 10': 10079156960 cycles # 0.000 GHz 10.004547117 seconds time elapsed That means, if I want 100 samples/sec: = 10079156960/(10*100)=10079157 $ perf record -e cycles -c 10079157 noploop 10 $ perf report -D | tail -20 cycles stats: TOTAL events: 1003 MMAP events: 11 COMM events: 2 EXIT events: 2 THROTTLE events: 1 UNTHROTTLE events: 1 SAMPLE events: 986 Now, we're getting the right answer! Just to confirm, for me: $ perf stat -e cycles ./noploop 10 noploop for 10 seconds Performance counter stats for './noploop 10': 4001163930 cycles # 0.000 GHz 10.006534024 seconds time elapsed $ perf record -e cycles -c 4001163 ./noploop 10 $ perf report -D | tail -20 Aggregated stats: TOTAL events: 1020 MMAP events: 18 COMM events: 2 EXIT events: 2 SAMPLE events: 998 cycles stats: TOTAL events: 1020 MMAP events: 18 COMM events: 2 EXIT events: 2 SAMPLE events: 998 which is close enough :) We need to elucidate what's going on in perf_event_task_tick(). I have tried with my throttling fix and it did not help. We are not subject to throttling with such a low rate. Ok. I would start by looking at the clock ticks if I were you, since this seems to be alright on my board. Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi,
Ok, so I did a few more tests and there is a serious issue when sampling
in frequency mode (the default). I noticed wrong number of samples, so
I investigated this some more and instrumented the perf_event kernel code.
I found some erratic timer ticks causing broken period adjustments.
In fact, the problem is visible using top.
I am running a noploop program on CPU0 and nothing else besides top.
The noploop program does: for(;;);. That is 100% user. On a 2-way
system otherwise idle, I expect top to return 50% user 50% idle.
Top with the commit:
top - 16:19:21 up 5 min, 1 user, load average: 0.23, 0.15, 0.07
Tasks: 70 total, 2 running, 68 sleeping, 0 stopped, 0 zombie
Cpu(s): 31.1%us, 2.0%sy, 0.0%ni, 66.2%id, 0.0%wa, 0.0%hi, 0.7%si, 0.0%st
That's WRONG
Mem:940292k total,74984k used, 865308k free, 8020k buffers
Swap: 524240k total,0k used, 524240k free,37420k cached
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
3770 eranian 20 0 644 160 128 R 99 0.0 0:14.21 noploop
3771 eranian 20 0 2184 1052 804 R2 0.1 0:00.32 top
1 root 20 0 2564 1528 952 S0 0.2 0:01.26 init
I removed that one liner patch from Ming. The one fiddling with the
clockdomains:
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags= CLKDM_CAN_HWSUP,
+ .flags= CLKDM_CAN_SWSUP,
When I rerun, the test, it now work:
top - 16:02:51 up 15 min, 1 user, load average: 1.02, 0.46, 0.21
Tasks: 70 total, 2 running, 68 sleeping, 0 stopped, 0 zombie
Cpu(s): 47.2%us, 1.0%sy, 0.0%ni, 50.8%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st
close enough (in it stabilize somehow around 49%
which is good)
Mem:940292k total,75288k used, 865004k free, 8004k buffers
Swap: 524240k total,0k used, 524240k free,37408k cached
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
3771 eranian 20 0 644 160 128 R 100 0.0 0:34.44 noploop
Although the patch fixes PMU interrupts, it breaks the timer tick logic somehow.
The perf problem is related to timer tick.
I am hoping that the tradeoff is not:
PMU interrupts but broken timer ticks
vs.
No PMU interrupts but working timer ticks
On Fri, Jan 27, 2012 at 6:16 PM, stephane eranian
eran...@googlemail.com wrote:
On Fri, Jan 27, 2012 at 6:10 PM, Will Deacon will.dea...@arm.com wrote:
On Fri, Jan 27, 2012 at 05:03:28PM +, stephane eranian wrote:
On Fri, Jan 27, 2012 at 5:59 PM, Will Deacon will.dea...@arm.com wrote:
That said, if you see any bugs in the code please do shout!
I suspect there is something wrong, we shouldn't hit the max_rate_limit.
You may have bursts of interrupts (samples). I'll check on that this
week-end.
Ok, thanks. Keep in mind that you probably have variable rate clocks, which
will affect the cycle counter frequency.
I assume it does not vary the clock if the workload is steady and just burning
cycles, e.g.: for(;;);
A7 and A15 have the ability to filter counters based on privilege
level, so
you can get more accurate userspace counts there.
Ok, that's better. Need to update libpfm4 for A15 with priv levels then!
How do you handle that in libpfm4? On ARM, the event encodings remain the
same,
you just need to set some extra bits to determine which levels are
included or
excluded (you can do this with the perf tool by using the :{u,k,h} suffix
on an
event description).
It depends what you call the encoding? If the priv level can be encoded in
the
attr-config field, then that's easy. If it needs to be set somewhere else,
then
we need to figure out how you encode it in the attr struct. Either in some
other
bits in attr-config or use attr-config1, for instance. You tell me.
The way it's done with perf is to set the exclude{user,kernel,hv} fields in
the attr. The ARM perf backend then translates these into the relevant bits
which get orred into the config_base before hitting the hardware.
Well, that's also how we do it with libpfm4 on X86. This is because
with perf_events,
the exclude_* fields have priority over what you set in the attr-config
field.
Will
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi guys, On Sat, Jan 21, 2012 at 09:16:57AM +, stephane eranian wrote: On Sat, Jan 21, 2012 at 4:25 AM, Ming Lei ming@canonical.com wrote: On Fri, Jan 20, 2012 at 9:47 PM, stephane eranian eran...@googlemail.com wrote: Started afresh from: 90a4c0f uml: fix compile for x86-64 And added 3, 4, 5, 6: 603c316 arm: omap4: pmu: support runtime pm 4899fbd arm: omap4: support pmu d737bb1 arm: omap4: create pmu device via hwmod 4e0259e arm: omap4: hwmod: introduce emu hwmod Still no interrupts firing. I am using your .config file. My HW: CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x1 CPU part : 0xc09 CPU revision : 2 Hardware : OMAP4 Panda board Revision : 0020 There must be something I am missing here. Did this lead anywhere in the end? It seems as though Ming Lei has a working setup but Stephane is unable to replicate it, despite applying the necessary patches and trying an updated bootloader. Drastic suggestion: Stephane, could you try a kernel *binary* from Ming Lei? If that works then you're probably just missing a patch. If it doesn't, then there must be something different between your boards. Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Fri, Jan 27, 2012 at 1:13 PM, Will Deacon will.dea...@arm.com wrote: Hi guys, On Sat, Jan 21, 2012 at 09:16:57AM +, stephane eranian wrote: On Sat, Jan 21, 2012 at 4:25 AM, Ming Lei ming@canonical.com wrote: On Fri, Jan 20, 2012 at 9:47 PM, stephane eranian eran...@googlemail.com wrote: Started afresh from: 90a4c0f uml: fix compile for x86-64 And added 3, 4, 5, 6: 603c316 arm: omap4: pmu: support runtime pm 4899fbd arm: omap4: support pmu d737bb1 arm: omap4: create pmu device via hwmod 4e0259e arm: omap4: hwmod: introduce emu hwmod Still no interrupts firing. I am using your .config file. My HW: CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x1 CPU part : 0xc09 CPU revision : 2 Hardware : OMAP4 Panda board Revision : 0020 There must be something I am missing here. Did this lead anywhere in the end? It seems as though Ming Lei has a working setup but Stephane is unable to replicate it, despite applying the necessary patches and trying an updated bootloader. Drastic suggestion: Stephane, could you try a kernel *binary* from Ming Lei? If that works then you're probably just missing a patch. If it doesn't, then there must be something different between your boards. Sure, send me the binary+initrd and I can try it out. Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Will Deacon will.dea...@arm.com writes: Hi guys, On Sat, Jan 21, 2012 at 09:16:57AM +, stephane eranian wrote: On Sat, Jan 21, 2012 at 4:25 AM, Ming Lei ming@canonical.com wrote: On Fri, Jan 20, 2012 at 9:47 PM, stephane eranian eran...@googlemail.com wrote: Started afresh from: 90a4c0f uml: fix compile for x86-64 And added 3, 4, 5, 6: 603c316 arm: omap4: pmu: support runtime pm 4899fbd arm: omap4: support pmu d737bb1 arm: omap4: create pmu device via hwmod 4e0259e arm: omap4: hwmod: introduce emu hwmod Still no interrupts firing. I am using your .config file. My HW: CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x1 CPU part : 0xc09 CPU revision : 2 Hardware : OMAP4 Panda board Revision : 0020 There must be something I am missing here. Did this lead anywhere in the end? It seems as though Ming Lei has a working setup but Stephane is unable to replicate it, despite applying the necessary patches and trying an updated bootloader. With the patches listed above plus the one in [1], I get PMU interrupts. However, unless I restrict the profiled process to one CPU (taskset 1 perf record ...), I get a panic in armpmu_event_update() with the 'event' argument being null when called from armv7pmu_handle_irq(). [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696 -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Mans, On Fri, Jan 27, 2012 at 12:56:35PM +, Måns Rullgård wrote: Will Deacon will.dea...@arm.com writes: Did this lead anywhere in the end? It seems as though Ming Lei has a working setup but Stephane is unable to replicate it, despite applying the necessary patches and trying an updated bootloader. With the patches listed above plus the one in [1], I get PMU interrupts. However, unless I restrict the profiled process to one CPU (taskset 1 perf record ...), I get a panic in armpmu_event_update() with the 'event' argument being null when called from armv7pmu_handle_irq(). [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696 Great, thanks for trying this out. Which version of the kernel were you using? I fixed a bunch of NULL pointer derefs. during the 3.2 window, but if you were using an -rc kernel you have have hit one of them. Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
2012/1/27 Will Deacon will.dea...@arm.com:
Mans,
On Fri, Jan 27, 2012 at 12:56:35PM +, Måns Rullgård wrote:
Will Deacon will.dea...@arm.com writes:
Did this lead anywhere in the end? It seems as though Ming Lei has a
working
setup but Stephane is unable to replicate it, despite applying the
necessary
patches and trying an updated bootloader.
With the patches listed above plus the one in [1], I get PMU interrupts.
However, unless I restrict the profiled process to one CPU
(taskset 1 perf record ...), I get a panic in armpmu_event_update() with
the 'event' argument being null when called from armv7pmu_handle_irq().
[1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696
Ok, I am recompiling the kernel for this one line fix:
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags= CLKDM_CAN_HWSUP,
+ .flags= CLKDM_CAN_SWSUP,
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Will Deacon will.dea...@arm.com writes: Mans, On Fri, Jan 27, 2012 at 12:56:35PM +, Måns Rullgård wrote: Will Deacon will.dea...@arm.com writes: Did this lead anywhere in the end? It seems as though Ming Lei has a working setup but Stephane is unable to replicate it, despite applying the necessary patches and trying an updated bootloader. With the patches listed above plus the one in [1], I get PMU interrupts. However, unless I restrict the profiled process to one CPU (taskset 1 perf record ...), I get a panic in armpmu_event_update() with the 'event' argument being null when called from armv7pmu_handle_irq(). [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696 Great, thanks for trying this out. Which version of the kernel were you using? I fixed a bunch of NULL pointer derefs. during the 3.2 window, but if you were using an -rc kernel you have have hit one of them. This was with the Linaro tilt-3.2 kernel from git://git.linaro.org/landing-teams/working/ti/kernel.git, commit 73e2c29f209d281f7cd10b52b53b087e74f1. Maybe one of the many patches it has on top of 3.2 is to blame. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Fri, Jan 27, 2012 at 01:47:01PM +, Måns Rullgård wrote: Will Deacon will.dea...@arm.com writes: Mans, On Fri, Jan 27, 2012 at 12:56:35PM +, Måns Rullgård wrote: Will Deacon will.dea...@arm.com writes: Did this lead anywhere in the end? It seems as though Ming Lei has a working setup but Stephane is unable to replicate it, despite applying the necessary patches and trying an updated bootloader. With the patches listed above plus the one in [1], I get PMU interrupts. However, unless I restrict the profiled process to one CPU (taskset 1 perf record ...), I get a panic in armpmu_event_update() with the 'event' argument being null when called from armv7pmu_handle_irq(). [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696 Great, thanks for trying this out. Which version of the kernel were you using? I fixed a bunch of NULL pointer derefs. during the 3.2 window, but if you were using an -rc kernel you have have hit one of them. This was with the Linaro tilt-3.2 kernel from git://git.linaro.org/landing-teams/working/ti/kernel.git, commit 73e2c29f209d281f7cd10b52b53b087e74f1. Maybe one of the many patches it has on top of 3.2 is to blame. Perhaps, or (more likely) the interrupt affinity for the CTI isn't working properly and the interrupt is always delivered to CPU0. I'll keep this in mind in case we get any more reports like this. Cheers, Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Will Deacon will.dea...@arm.com writes: On Fri, Jan 27, 2012 at 01:47:01PM +, Måns Rullgård wrote: Will Deacon will.dea...@arm.com writes: Mans, On Fri, Jan 27, 2012 at 12:56:35PM +, Måns Rullgård wrote: Will Deacon will.dea...@arm.com writes: Did this lead anywhere in the end? It seems as though Ming Lei has a working setup but Stephane is unable to replicate it, despite applying the necessary patches and trying an updated bootloader. With the patches listed above plus the one in [1], I get PMU interrupts. However, unless I restrict the profiled process to one CPU (taskset 1 perf record ...), I get a panic in armpmu_event_update() with the 'event' argument being null when called from armv7pmu_handle_irq(). [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696 Great, thanks for trying this out. Which version of the kernel were you using? I fixed a bunch of NULL pointer derefs. during the 3.2 window, but if you were using an -rc kernel you have have hit one of them. This was with the Linaro tilt-3.2 kernel from git://git.linaro.org/landing-teams/working/ti/kernel.git, commit 73e2c29f209d281f7cd10b52b53b087e74f1. Maybe one of the many patches it has on top of 3.2 is to blame. Perhaps, or (more likely) the interrupt affinity for the CTI isn't working properly and the interrupt is always delivered to CPU0. I'll keep this in mind in case we get any more reports like this. It works whichever CPU I pin it to (i.e. taskset 2 also works). FWIW, my /proc/interrupts looks like this when perf is running: CPU0 CPU1 29: 252381271409121 GIC twd 33:4586197 0 GIC arm-pmu 34: 04744550 GIC arm-pmu 39: 0 0 GIC TWL6030-PIH 41: 0 0 GIC l3-dbg-irq 42: 0 0 GIC l3-app-irq 43: 0 0 GIC prcm 44:141 0 GIC DMA [...] -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi, On Fri, Jan 27, 2012 at 8:13 PM, Will Deacon will.dea...@arm.com wrote: There must be something I am missing here. Did this lead anywhere in the end? It seems as though Ming Lei has a working setup but Stephane is unable to replicate it, despite applying the necessary patches and trying an updated bootloader. In fact, I don't think stephane has tried the patch in the link[1] and reported the test result, even though I have asked him to do it for several times. Drastic suggestion: Stephane, could you try a kernel *binary* from Ming Lei? If that works then you're probably just missing a patch. If it doesn't, then there must be something different between your boards. [1], http://marc.info/?l=linux-arm-kernelm=132697975416659w=2 thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi, 2012/1/27 Will Deacon will.dea...@arm.com: Mans, On Fri, Jan 27, 2012 at 12:56:35PM +, Måns Rullgård wrote: Will Deacon will.dea...@arm.com writes: Did this lead anywhere in the end? It seems as though Ming Lei has a working setup but Stephane is unable to replicate it, despite applying the necessary patches and trying an updated bootloader. With the patches listed above plus the one in [1], I get PMU interrupts. However, unless I restrict the profiled process to one CPU (taskset 1 perf record ...), I get a panic in armpmu_event_update() with the 'event' argument being null when called from armv7pmu_handle_irq(). [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696 Great, thanks for trying this out. Which version of the kernel were you using? The patch is required for 3.3-rc1 in case that omap4 pmu works well. thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi, Ok, with the one-line patch [1], this works much better now. No more wrap around a 4 billion cycles. Sampling is okay, though I noticed it tends to not get the correct number of samples for a controlled run: $ perf record -e cycles -c 1009213 noploop 10 noploop for 10 seconds $ perf report -D | tail -20 cycles stats: TOTAL events: 9938 MMAP events: 13 COMM events: 2 EXIT events: 2 THROTTLE events: 12 UNTHROTTLE events: 12 SAMPLE events: 9897 Should not get throttled samples. Should get abour 10k samples but only seeing 9897. The max_rate limit is way higher than what I set the period (1000 samples/sec). But then, is 3.2.0 throttling is broken. I posted a patch to fix that yesterday. I will try with my patch applied as well. Will do some more testing and update to the latest 3.3.0-rc1. For now this is with 3.2.0 Linus tree. $ sudo ./syst_count -c 1 -p -e cpu_cycles press CTRL-C to quit before 20s time limit # 1s - CPU1 G0 1008360963 cpu_cycles (scaling 0.00%, ena=1000427246, run=1000427246) # 2s - CPU1 G0 2016503406 cpu_cycles (scaling 0.00%, ena=2000610351, run=2000610351) # 3s - CPU1 G0 3024622201 cpu_cycles (scaling 0.00%, ena=3000701904, run=3000701904) # 4s - CPU1 G0 4032753756 cpu_cycles (scaling 0.00%, ena=4000823974, run=4000823974) # 5s - CPU1 G0 5041040463 cpu_cycles (scaling 0.00%, ena=5001098633, run=5001098633) # 6s - CPU1 G0 6049184665 cpu_cycles (scaling 0.00%, ena=6001220703, run=6001220703) # 7s - CPU1 G0 7057336298 cpu_cycles (scaling 0.00%, ena=7001403808, run=7001403808) # 8s - CPU1 G0 8065459152 cpu_cycles (scaling 0.00%, ena=8001556395, run=8001556395) # 9s - CPU1 G0 9074297578 cpu_cycles (scaling 0.00%, ena=9002380370, run=9002380370) # 10s - CPU1 G0 10082619086 cpu_cycles (scaling 0.00%, ena=10003540038, run=10003540038) On Fri, Jan 27, 2012 at 3:09 PM, Ming Lei ming@canonical.com wrote: Hi, 2012/1/27 Will Deacon will.dea...@arm.com: Mans, On Fri, Jan 27, 2012 at 12:56:35PM +, Måns Rullgård wrote: Will Deacon will.dea...@arm.com writes: Did this lead anywhere in the end? It seems as though Ming Lei has a working setup but Stephane is unable to replicate it, despite applying the necessary patches and trying an updated bootloader. With the patches listed above plus the one in [1], I get PMU interrupts. However, unless I restrict the profiled process to one CPU (taskset 1 perf record ...), I get a panic in armpmu_event_update() with the 'event' argument being null when called from armv7pmu_handle_irq(). [1] http://article.gmane.org/gmane.linux.ports.arm.omap/69696 Great, thanks for trying this out. Which version of the kernel were you using? The patch is required for 3.3-rc1 in case that omap4 pmu works well. thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Fri, Jan 27, 2012 at 03:45:53PM +, stephane eranian wrote: Hi, Hi Stephane, Ok, with the one-line patch [1], this works much better now. No more wrap around a 4 billion cycles. Hurrah! Thanks Mans and Ming Lei for helping with this. Unfortunately, I remember Santosh had objections to this patch so that needs to be resolved. Sampling is okay, though I noticed it tends to not get the correct number of samples for a controlled run: $ perf record -e cycles -c 1009213 noploop 10 noploop for 10 seconds $ perf report -D | tail -20 cycles stats: TOTAL events: 9938 MMAP events: 13 COMM events: 2 EXIT events: 2 THROTTLE events: 12 UNTHROTTLE events: 12 SAMPLE events: 9897 Should not get throttled samples. Should get abour 10k samples but only seeing 9897. The max_rate limit is way higher than what I set the period (1000 samples/sec). But then, is 3.2.0 throttling is broken. I posted a patch to fix that yesterday. I will try with my patch applied as well. Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so you may miss samples if they occur during critical kernel sections (and if you look at a profile, spin_unlock_irqrestore will be quite high). A7 and A15 have the ability to filter counters based on privilege level, so you can get more accurate userspace counts there. Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Fri, Jan 27, 2012 at 4:54 PM, Will Deacon will.dea...@arm.com wrote: On Fri, Jan 27, 2012 at 03:45:53PM +, stephane eranian wrote: Hi, Hi Stephane, Ok, with the one-line patch [1], this works much better now. No more wrap around a 4 billion cycles. Hurrah! Thanks Mans and Ming Lei for helping with this. Unfortunately, I remember Santosh had objections to this patch so that needs to be resolved. Yes, this needs to be resolved ASAP. Sampling is okay, though I noticed it tends to not get the correct number of samples for a controlled run: $ perf record -e cycles -c 1009213 noploop 10 noploop for 10 seconds $ perf report -D | tail -20 cycles stats: TOTAL events: 9938 MMAP events: 13 COMM events: 2 EXIT events: 2 THROTTLE events: 12 UNTHROTTLE events: 12 SAMPLE events: 9897 Should not get throttled samples. Should get abour 10k samples but only seeing 9897. The max_rate limit is way higher than what I set the period (1000 samples/sec). But then, is 3.2.0 throttling is broken. I posted a patch to fix that yesterday. I will try with my patch applied as well. Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so you may miss samples if they occur during critical kernel sections (and if you look at a profile, spin_unlock_irqrestore will be quite high). But I am only running a user space noploop. So it spends 99% in user space, no critical section. A7 and A15 have the ability to filter counters based on privilege level, so you can get more accurate userspace counts there. Ok, that's better. Need to update libpfm4 for A15 with priv levels then! Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Fri, Jan 27, 2012 at 03:57:25PM +, stephane eranian wrote:
On Fri, Jan 27, 2012 at 4:54 PM, Will Deacon will.dea...@arm.com wrote:
Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so
you may miss samples if they occur during critical kernel sections (and if
you look at a profile, spin_unlock_irqrestore will be quite high).
But I am only running a user space noploop. So it spends 99% in user space, no
critical section.
and your result is almost 99% of the way there :)
There are also potential overheads from the PMU interrupts themselves, since
there is a latency between overflow and taking the interrupt and then
between there are actually reading the counter (they continue to count after
overflow).
That said, if you see any bugs in the code please do shout!
A7 and A15 have the ability to filter counters based on privilege level, so
you can get more accurate userspace counts there.
Ok, that's better. Need to update libpfm4 for A15 with priv levels then!
How do you handle that in libpfm4? On ARM, the event encodings remain the same,
you just need to set some extra bits to determine which levels are included or
excluded (you can do this with the perf tool by using the :{u,k,h} suffix on an
event description).
Will
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Fri, Jan 27, 2012 at 5:59 PM, Will Deacon will.dea...@arm.com wrote:
On Fri, Jan 27, 2012 at 03:57:25PM +, stephane eranian wrote:
On Fri, Jan 27, 2012 at 4:54 PM, Will Deacon will.dea...@arm.com wrote:
Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so
you may miss samples if they occur during critical kernel sections (and if
you look at a profile, spin_unlock_irqrestore will be quite high).
But I am only running a user space noploop. So it spends 99% in user space,
no
critical section.
and your result is almost 99% of the way there :)
There are also potential overheads from the PMU interrupts themselves, since
there is a latency between overflow and taking the interrupt and then
between there are actually reading the counter (they continue to count after
overflow).
That said, if you see any bugs in the code please do shout!
I suspect there is something wrong, we shouldn't hit the max_rate_limit.
You may have bursts of interrupts (samples). I'll check on that this week-end.
A7 and A15 have the ability to filter counters based on privilege level, so
you can get more accurate userspace counts there.
Ok, that's better. Need to update libpfm4 for A15 with priv levels then!
How do you handle that in libpfm4? On ARM, the event encodings remain the
same,
you just need to set some extra bits to determine which levels are included or
excluded (you can do this with the perf tool by using the :{u,k,h} suffix on
an
event description).
It depends what you call the encoding? If the priv level can be encoded in the
attr-config field, then that's easy. If it needs to be set somewhere else, then
we need to figure out how you encode it in the attr struct. Either in some other
bits in attr-config or use attr-config1, for instance. You tell me.
Will
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Fri, Jan 27, 2012 at 05:03:28PM +, stephane eranian wrote:
On Fri, Jan 27, 2012 at 5:59 PM, Will Deacon will.dea...@arm.com wrote:
That said, if you see any bugs in the code please do shout!
I suspect there is something wrong, we shouldn't hit the max_rate_limit.
You may have bursts of interrupts (samples). I'll check on that this week-end.
Ok, thanks. Keep in mind that you probably have variable rate clocks, which
will affect the cycle counter frequency.
A7 and A15 have the ability to filter counters based on privilege level,
so
you can get more accurate userspace counts there.
Ok, that's better. Need to update libpfm4 for A15 with priv levels then!
How do you handle that in libpfm4? On ARM, the event encodings remain the
same,
you just need to set some extra bits to determine which levels are included
or
excluded (you can do this with the perf tool by using the :{u,k,h} suffix
on an
event description).
It depends what you call the encoding? If the priv level can be encoded in the
attr-config field, then that's easy. If it needs to be set somewhere else,
then
we need to figure out how you encode it in the attr struct. Either in some
other
bits in attr-config or use attr-config1, for instance. You tell me.
The way it's done with perf is to set the exclude{user,kernel,hv} fields in
the attr. The ARM perf backend then translates these into the relevant bits
which get orred into the config_base before hitting the hardware.
Will
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Fri, Jan 27, 2012 at 6:10 PM, Will Deacon will.dea...@arm.com wrote:
On Fri, Jan 27, 2012 at 05:03:28PM +, stephane eranian wrote:
On Fri, Jan 27, 2012 at 5:59 PM, Will Deacon will.dea...@arm.com wrote:
That said, if you see any bugs in the code please do shout!
I suspect there is something wrong, we shouldn't hit the max_rate_limit.
You may have bursts of interrupts (samples). I'll check on that this
week-end.
Ok, thanks. Keep in mind that you probably have variable rate clocks, which
will affect the cycle counter frequency.
I assume it does not vary the clock if the workload is steady and just burning
cycles, e.g.: for(;;);
A7 and A15 have the ability to filter counters based on privilege
level, so
you can get more accurate userspace counts there.
Ok, that's better. Need to update libpfm4 for A15 with priv levels then!
How do you handle that in libpfm4? On ARM, the event encodings remain the
same,
you just need to set some extra bits to determine which levels are
included or
excluded (you can do this with the perf tool by using the :{u,k,h} suffix
on an
event description).
It depends what you call the encoding? If the priv level can be encoded in
the
attr-config field, then that's easy. If it needs to be set somewhere else,
then
we need to figure out how you encode it in the attr struct. Either in some
other
bits in attr-config or use attr-config1, for instance. You tell me.
The way it's done with perf is to set the exclude{user,kernel,hv} fields in
the attr. The ARM perf backend then translates these into the relevant bits
which get orred into the config_base before hitting the hardware.
Well, that's also how we do it with libpfm4 on X86. This is because
with perf_events,
the exclude_* fields have priority over what you set in the attr-config field.
Will
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Sat, Jan 21, 2012 at 4:25 AM, Ming Lei ming@canonical.com wrote: On Fri, Jan 20, 2012 at 9:47 PM, stephane eranian eran...@googlemail.com wrote: Started afresh from: 90a4c0f uml: fix compile for x86-64 And added 3, 4, 5, 6: 603c316 arm: omap4: pmu: support runtime pm 4899fbd arm: omap4: support pmu d737bb1 arm: omap4: create pmu device via hwmod 4e0259e arm: omap4: hwmod: introduce emu hwmod Still no interrupts firing. I am using your .config file. My HW: CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x1 CPU part : 0xc09 CPU revision : 2 Hardware : OMAP4 Panda board Revision : 0020 There must be something I am missing here. Have you applied the patch in link[1]? You mean this: [1], http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary It does not point to a patch but to the entire tree. thanks, -- Ming Lei [1], http://marc.info/?l=linux-arm-kernelm=132697975416659w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Started afresh from:
90a4c0f uml: fix compile for x86-64
And added 3, 4, 5, 6:
603c316 arm: omap4: pmu: support runtime pm
4899fbd arm: omap4: support pmu
d737bb1 arm: omap4: create pmu device via hwmod
4e0259e arm: omap4: hwmod: introduce emu hwmod
Still no interrupts firing. I am using your .config file.
My HW:
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x1
CPU part: 0xc09
CPU revision: 2
Hardware: OMAP4 Panda board
Revision: 0020
There must be something I am missing here.
On Thu, Jan 19, 2012 at 6:07 PM, stephane eranian
eran...@googlemail.com wrote:
Just did a fresh clone of Linus' tree:
$ git log --oneline | fgrep 'allow platform specific'
e0516a6 arm: pmu: allow platform specific irq enable/disable handling
$ git log --oneline | fgrep 'cross trigger'
14eec97 arm: introduce cross trigger interface helpers
Unless you were referring to a different pair of patches.
On Thu, Jan 19, 2012 at 2:51 PM, Ming Lei ming@canonical.com wrote:
Hi,
On Thu, Jan 19, 2012 at 9:32 PM, stephane eranian
eran...@googlemail.com wrote:
On Thu, Jan 19, 2012 at 2:26 PM, Ming Lei ming@canonical.com wrote:
Hi,
On Thu, Jan 19, 2012 at 9:14 PM, Ming Lei ming@canonical.com wrote:
On Thu, Jan 19, 2012 at 8:51 PM, stephane eranian
eran...@googlemail.com wrote:
On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei ming@canonical.com wrote:
Hi,
On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
eran...@googlemail.com wrote:
Hi,
Ok some update on this.
With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a
kernel that
You forget patch 1 and patch 2?
They are already in 3.2.0. Unless I am mistaken.
Sorry, I just found that they have been merged to 3.2.
After a double check, the two patches are not merged to 3.2, but have
been merged to the latest linus tree and can be seen in 3.3-rc1.
Also the commit 3c50729b(ARM: OMAP4: PM: Initialise all the clockdomains
to supported states) has been merged to linus tree too.
So if you just tested the latest linus tree simply, you need to apply
the patch[1]
(I have mentioned the problem in the thread.)
Changing LMO, u-boot.bin did not help. Even with perf top I get no
interrupts.
My Linus tree is at commit fa1952b:
[6] 11891e1 arm: omap4: pmu: support runtime pm
[5] 25fab8a arm: omap4: support pmu
[4] fddef77 arm: omap4: create pmu device via hwmod
fa1952b ARM: OMAP4: hwmod data: Add support for the debug modules
Sorry, there is no commit fa1952b in linus[1] tree at all, so you are
not testing
linus tree...
If you'd like to follow my instructions, I can help you further.
ccb19d2 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
c3b5003 tg3: Fix single-vector MSI-X code
I think [1] had conflicts when applying it to the tree.
It is only one line(one character) change, you can do it manually.
thanks,
--
Ming Lei
[1],
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..41d2260 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_SWSUP,
};
[1], http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary
thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Fri, Jan 20, 2012 at 9:47 PM, stephane eranian eran...@googlemail.com wrote: Started afresh from: 90a4c0f uml: fix compile for x86-64 And added 3, 4, 5, 6: 603c316 arm: omap4: pmu: support runtime pm 4899fbd arm: omap4: support pmu d737bb1 arm: omap4: create pmu device via hwmod 4e0259e arm: omap4: hwmod: introduce emu hwmod Still no interrupts firing. I am using your .config file. My HW: CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x1 CPU part : 0xc09 CPU revision : 2 Hardware : OMAP4 Panda board Revision : 0020 There must be something I am missing here. Have you applied the patch in link[1]? thanks, -- Ming Lei [1], http://marc.info/?l=linux-arm-kernelm=132697975416659w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi, Ok some update on this. With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that boots. It does recognize the PMU. However, it still does not count correctly and I believe for the same reason.: no interrupts are delivered. I run a cycle burner program on CPU0, I watch /proc/interrupts. and then I run libpfm4 program that does per-cpu monitoring on CPU0 and print the counts every second: $ sudo ./syst_count -d 10 -p -c 0 -e cpu_cycles press CTRL-C to quit before 10s time limit # 1s - CPU0 G0 1008129147 cpu_cycles (scaling 0.00%, ena=1000152588, run=1000152588) # 2s - CPU0 G0 2016240766 cpu_cycles (scaling 0.00%, ena=2000335693, run=2000335693) # 3s - CPU0 G0 3024249265 cpu_cycles (scaling 0.00%, ena=3000427245, run=3000427245) # 4s - CPU0 G0 4072779364 cpu_cycles (scaling 0.00%, ena=4040710449, run=4040710449) # 5s - CPU0 G0 785954705cpu_cycles (scaling 0.00%, ena=5040954589, run=5040954589) # 6s - CPU0 G0 1803397848 cpu_cycles (scaling 0.00%, ena=6050384520, run=6050384520) # 7s - You clearly see that after 4s you've reached the 32-bit limit of the counter and then you wrap around. It should show 5 billions or so cycles. Over the entire run, no arm-pmu interrupt was delivered according to /proc/interrupts. I guess you can test the same condition using perf directly, use a program that burns cycles for a know duration. Try 4s and then 4s. I use 1s vs. 10s and I expect the count to be 10x larger in the latter test case. If it's not then, interrupts are not coming in, On Thu, Jan 19, 2012 at 2:21 AM, Ming Lei ming@canonical.com wrote: Hi, On Thu, Jan 19, 2012 at 5:58 AM, stephane eranian eran...@googlemail.com wrote: Ming, Ok, so I used Linus' tree @ It already includes patches #1 and #2. I applied 4-6. The patch #3 is missed? Recompiled but my kernel does not boot, I don't see anything on the serial console. Could be a broken I don't think that the patches can cause your non boot, you can try the linus tree kernel first, then try the patches. .config file. Could you send me your .config for Panda? See the attachment. Thanks. On Wed, Jan 18, 2012 at 11:07 AM, Ming Lei ming@canonical.com wrote: Hi, On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian eran...@googlemail.com Should I use Will's -next tree as the base instead of Linus'? Either one is OK. If you use linus tree as base, you need to apply the #1 and #2 patch manually. Given that MARC is shutdown today, would you mind packing those patches into a tarball and sending them to me directly? See attachment, which includes the patches from #3 to #6. When you mention Will's -next tree, are you talking about: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf It is perf/omap4 brach, you can pick up the two patches[1][2] directly from the branch. thanks, -- Ming Lei [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi, On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian eran...@googlemail.com wrote: Hi, Ok some update on this. With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that You forget patch 1 and patch 2? boots. It does recognize the PMU. However, it still does not count correctly and I believe for the same reason.: no interrupts are delivered. I run a cycle burner program on CPU0, I watch /proc/interrupts. and then I run libpfm4 program that does per-cpu monitoring on CPU0 and print the counts every second: I just run 'perf top', then watch output of '/proc/interrupts' in another terminal. I am sure I can see perf is OK and interrupts are generated on my pandaboard. $ sudo ./syst_count -d 10 -p -c 0 -e cpu_cycles press CTRL-C to quit before 10s time limit # 1s - CPU0 G0 1008129147 cpu_cycles (scaling 0.00%, ena=1000152588, run=1000152588) # 2s - CPU0 G0 2016240766 cpu_cycles (scaling 0.00%, ena=2000335693, run=2000335693) # 3s - CPU0 G0 3024249265 cpu_cycles (scaling 0.00%, ena=3000427245, run=3000427245) # 4s - CPU0 G0 4072779364 cpu_cycles (scaling 0.00%, ena=4040710449, run=4040710449) # 5s - CPU0 G0 785954705 cpu_cycles (scaling 0.00%, ena=5040954589, run=5040954589) # 6s - CPU0 G0 1803397848 cpu_cycles (scaling 0.00%, ena=6050384520, run=6050384520) # 7s - You clearly see that after 4s you've reached the 32-bit limit of the counter and then you wrap around. It should show 5 billions or so cycles. Over the entire run, no arm-pmu interrupt was delivered according to /proc/interrupts. I guess you can test the same condition using perf directly, use a program that burns cycles for a know duration. Try 4s and then 4s. I use 1s vs. 10s and I expect the count to be 10x larger in the latter test case. If it's not then, interrupts are not coming in, On Thu, Jan 19, 2012 at 2:21 AM, Ming Lei ming@canonical.com wrote: Hi, On Thu, Jan 19, 2012 at 5:58 AM, stephane eranian eran...@googlemail.com wrote: Ming, Ok, so I used Linus' tree @ It already includes patches #1 and #2. I applied 4-6. The patch #3 is missed? Recompiled but my kernel does not boot, I don't see anything on the serial console. Could be a broken I don't think that the patches can cause your non boot, you can try the linus tree kernel first, then try the patches. .config file. Could you send me your .config for Panda? See the attachment. Thanks. On Wed, Jan 18, 2012 at 11:07 AM, Ming Lei ming@canonical.com wrote: Hi, On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian eran...@googlemail.com Should I use Will's -next tree as the base instead of Linus'? Either one is OK. If you use linus tree as base, you need to apply the #1 and #2 patch manually. Given that MARC is shutdown today, would you mind packing those patches into a tarball and sending them to me directly? See attachment, which includes the patches from #3 to #6. When you mention Will's -next tree, are you talking about: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf It is perf/omap4 brach, you can pick up the two patches[1][2] directly from the branch. thanks, -- Ming Lei [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei ming@canonical.com wrote: Hi, On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian eran...@googlemail.com wrote: Hi, Ok some update on this. With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that You forget patch 1 and patch 2? They are already in 3.2.0. Unless I am mistaken. are you sure you don't have anything else applied? boots. It does recognize the PMU. However, it still does not count correctly and I believe for the same reason.: no interrupts are delivered. I run a cycle burner program on CPU0, I watch /proc/interrupts. and then I run libpfm4 program that does per-cpu monitoring on CPU0 and print the counts every second: I just run 'perf top', then watch output of '/proc/interrupts' in another terminal. I am sure I can see perf is OK and interrupts are generated on my pandaboard. $ sudo ./syst_count -d 10 -p -c 0 -e cpu_cycles press CTRL-C to quit before 10s time limit # 1s - CPU0 G0 1008129147 cpu_cycles (scaling 0.00%, ena=1000152588, run=1000152588) # 2s - CPU0 G0 2016240766 cpu_cycles (scaling 0.00%, ena=2000335693, run=2000335693) # 3s - CPU0 G0 3024249265 cpu_cycles (scaling 0.00%, ena=3000427245, run=3000427245) # 4s - CPU0 G0 4072779364 cpu_cycles (scaling 0.00%, ena=4040710449, run=4040710449) # 5s - CPU0 G0 785954705 cpu_cycles (scaling 0.00%, ena=5040954589, run=5040954589) # 6s - CPU0 G0 1803397848 cpu_cycles (scaling 0.00%, ena=6050384520, run=6050384520) # 7s - You clearly see that after 4s you've reached the 32-bit limit of the counter and then you wrap around. It should show 5 billions or so cycles. Over the entire run, no arm-pmu interrupt was delivered according to /proc/interrupts. I guess you can test the same condition using perf directly, use a program that burns cycles for a know duration. Try 4s and then 4s. I use 1s vs. 10s and I expect the count to be 10x larger in the latter test case. If it's not then, interrupts are not coming in, On Thu, Jan 19, 2012 at 2:21 AM, Ming Lei ming@canonical.com wrote: Hi, On Thu, Jan 19, 2012 at 5:58 AM, stephane eranian eran...@googlemail.com wrote: Ming, Ok, so I used Linus' tree @ It already includes patches #1 and #2. I applied 4-6. The patch #3 is missed? Recompiled but my kernel does not boot, I don't see anything on the serial console. Could be a broken I don't think that the patches can cause your non boot, you can try the linus tree kernel first, then try the patches. .config file. Could you send me your .config for Panda? See the attachment. Thanks. On Wed, Jan 18, 2012 at 11:07 AM, Ming Lei ming@canonical.com wrote: Hi, On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian eran...@googlemail.com Should I use Will's -next tree as the base instead of Linus'? Either one is OK. If you use linus tree as base, you need to apply the #1 and #2 patch manually. Given that MARC is shutdown today, would you mind packing those patches into a tarball and sending them to me directly? See attachment, which includes the patches from #3 to #6. When you mention Will's -next tree, are you talking about: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf It is perf/omap4 brach, you can pick up the two patches[1][2] directly from the branch. thanks, -- Ming Lei [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Thu, Jan 19, 2012 at 1:51 PM, stephane eranian eran...@googlemail.com wrote: On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei ming@canonical.com wrote: Hi, On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian eran...@googlemail.com wrote: Hi, Ok some update on this. With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that You forget patch 1 and patch 2? They are already in 3.2.0. Unless I am mistaken. e0516a6 arm: pmu: allow platform specific irq enable/disable handling 14eec97 arm: introduce cross trigger interface helpers are you sure you don't have anything else applied? boots. It does recognize the PMU. However, it still does not count correctly and I believe for the same reason.: no interrupts are delivered. I run a cycle burner program on CPU0, I watch /proc/interrupts. and then I run libpfm4 program that does per-cpu monitoring on CPU0 and print the counts every second: I just run 'perf top', then watch output of '/proc/interrupts' in another terminal. I am sure I can see perf is OK and interrupts are generated on my pandaboard. $ sudo ./syst_count -d 10 -p -c 0 -e cpu_cycles press CTRL-C to quit before 10s time limit # 1s - CPU0 G0 1008129147 cpu_cycles (scaling 0.00%, ena=1000152588, run=1000152588) # 2s - CPU0 G0 2016240766 cpu_cycles (scaling 0.00%, ena=2000335693, run=2000335693) # 3s - CPU0 G0 3024249265 cpu_cycles (scaling 0.00%, ena=3000427245, run=3000427245) # 4s - CPU0 G0 4072779364 cpu_cycles (scaling 0.00%, ena=4040710449, run=4040710449) # 5s - CPU0 G0 785954705 cpu_cycles (scaling 0.00%, ena=5040954589, run=5040954589) # 6s - CPU0 G0 1803397848 cpu_cycles (scaling 0.00%, ena=6050384520, run=6050384520) # 7s - You clearly see that after 4s you've reached the 32-bit limit of the counter and then you wrap around. It should show 5 billions or so cycles. Over the entire run, no arm-pmu interrupt was delivered according to /proc/interrupts. I guess you can test the same condition using perf directly, use a program that burns cycles for a know duration. Try 4s and then 4s. I use 1s vs. 10s and I expect the count to be 10x larger in the latter test case. If it's not then, interrupts are not coming in, On Thu, Jan 19, 2012 at 2:21 AM, Ming Lei ming@canonical.com wrote: Hi, On Thu, Jan 19, 2012 at 5:58 AM, stephane eranian eran...@googlemail.com wrote: Ming, Ok, so I used Linus' tree @ It already includes patches #1 and #2. I applied 4-6. The patch #3 is missed? Recompiled but my kernel does not boot, I don't see anything on the serial console. Could be a broken I don't think that the patches can cause your non boot, you can try the linus tree kernel first, then try the patches. .config file. Could you send me your .config for Panda? See the attachment. Thanks. On Wed, Jan 18, 2012 at 11:07 AM, Ming Lei ming@canonical.com wrote: Hi, On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian eran...@googlemail.com Should I use Will's -next tree as the base instead of Linus'? Either one is OK. If you use linus tree as base, you need to apply the #1 and #2 patch manually. Given that MARC is shutdown today, would you mind packing those patches into a tarball and sending them to me directly? See attachment, which includes the patches from #3 to #6. When you mention Will's -next tree, are you talking about: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf It is perf/omap4 brach, you can pick up the two patches[1][2] directly from the branch. thanks, -- Ming Lei [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Thu, Jan 19, 2012 at 8:51 PM, stephane eranian eran...@googlemail.com wrote: On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei ming@canonical.com wrote: Hi, On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian eran...@googlemail.com wrote: Hi, Ok some update on this. With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that You forget patch 1 and patch 2? They are already in 3.2.0. Unless I am mistaken. Sorry, I just found that they have been merged to 3.2. are you sure you don't have anything else applied? Yes, I am sure, maybe it is caused by uboot and mlo, I will email them to you in private mail. thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi,
On Thu, Jan 19, 2012 at 9:14 PM, Ming Lei ming@canonical.com wrote:
On Thu, Jan 19, 2012 at 8:51 PM, stephane eranian
eran...@googlemail.com wrote:
On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei ming@canonical.com wrote:
Hi,
On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
eran...@googlemail.com wrote:
Hi,
Ok some update on this.
With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel
that
You forget patch 1 and patch 2?
They are already in 3.2.0. Unless I am mistaken.
Sorry, I just found that they have been merged to 3.2.
After a double check, the two patches are not merged to 3.2, but have
been merged to the latest linus tree and can be seen in 3.3-rc1.
Also the commit 3c50729b(ARM: OMAP4: PM: Initialise all the clockdomains
to supported states) has been merged to linus tree too.
So if you just tested the latest linus tree simply, you need to apply
the patch[1]
(I have mentioned the problem in the thread.)
thanks,
--
Ming Lei
[1],
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..41d2260 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags= CLKDM_CAN_HWSUP,
+ .flags= CLKDM_CAN_SWSUP,
};
static struct clockdomain l3_dma_44xx_clkdm = {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Thu, Jan 19, 2012 at 2:26 PM, Ming Lei ming@canonical.com wrote:
Hi,
On Thu, Jan 19, 2012 at 9:14 PM, Ming Lei ming@canonical.com wrote:
On Thu, Jan 19, 2012 at 8:51 PM, stephane eranian
eran...@googlemail.com wrote:
On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei ming@canonical.com wrote:
Hi,
On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
eran...@googlemail.com wrote:
Hi,
Ok some update on this.
With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel
that
You forget patch 1 and patch 2?
They are already in 3.2.0. Unless I am mistaken.
Sorry, I just found that they have been merged to 3.2.
After a double check, the two patches are not merged to 3.2, but have
been merged to the latest linus tree and can be seen in 3.3-rc1.
Also the commit 3c50729b(ARM: OMAP4: PM: Initialise all the clockdomains
to supported states) has been merged to linus tree too.
So if you just tested the latest linus tree simply, you need to apply
the patch[1]
(I have mentioned the problem in the thread.)
Changing LMO, u-boot.bin did not help. Even with perf top I get no
interrupts.
My Linus tree is at commit fa1952b:
[6] 11891e1 arm: omap4: pmu: support runtime pm
[5] 25fab8a arm: omap4: support pmu
[4] fddef77 arm: omap4: create pmu device via hwmod
fa1952b ARM: OMAP4: hwmod data: Add support for the debug modules
ccb19d2 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
c3b5003 tg3: Fix single-vector MSI-X code
I think [1] had conflicts when applying it to the tree.
thanks,
--
Ming Lei
[1],
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..41d2260 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_SWSUP,
};
static struct clockdomain l3_dma_44xx_clkdm = {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi,
On Thu, Jan 19, 2012 at 9:32 PM, stephane eranian
eran...@googlemail.com wrote:
On Thu, Jan 19, 2012 at 2:26 PM, Ming Lei ming@canonical.com wrote:
Hi,
On Thu, Jan 19, 2012 at 9:14 PM, Ming Lei ming@canonical.com wrote:
On Thu, Jan 19, 2012 at 8:51 PM, stephane eranian
eran...@googlemail.com wrote:
On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei ming@canonical.com wrote:
Hi,
On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
eran...@googlemail.com wrote:
Hi,
Ok some update on this.
With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a
kernel that
You forget patch 1 and patch 2?
They are already in 3.2.0. Unless I am mistaken.
Sorry, I just found that they have been merged to 3.2.
After a double check, the two patches are not merged to 3.2, but have
been merged to the latest linus tree and can be seen in 3.3-rc1.
Also the commit 3c50729b(ARM: OMAP4: PM: Initialise all the clockdomains
to supported states) has been merged to linus tree too.
So if you just tested the latest linus tree simply, you need to apply
the patch[1]
(I have mentioned the problem in the thread.)
Changing LMO, u-boot.bin did not help. Even with perf top I get no
interrupts.
My Linus tree is at commit fa1952b:
[6] 11891e1 arm: omap4: pmu: support runtime pm
[5] 25fab8a arm: omap4: support pmu
[4] fddef77 arm: omap4: create pmu device via hwmod
fa1952b ARM: OMAP4: hwmod data: Add support for the debug modules
Sorry, there is no commit fa1952b in linus[1] tree at all, so you are
not testing
linus tree...
If you'd like to follow my instructions, I can help you further.
ccb19d2 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
c3b5003 tg3: Fix single-vector MSI-X code
I think [1] had conflicts when applying it to the tree.
It is only one line(one character) change, you can do it manually.
thanks,
--
Ming Lei
[1],
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..41d2260 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_SWSUP,
};
[1], http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary
thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Just did a fresh clone of Linus' tree:
$ git log --oneline | fgrep 'allow platform specific'
e0516a6 arm: pmu: allow platform specific irq enable/disable handling
$ git log --oneline | fgrep 'cross trigger'
14eec97 arm: introduce cross trigger interface helpers
Unless you were referring to a different pair of patches.
On Thu, Jan 19, 2012 at 2:51 PM, Ming Lei ming@canonical.com wrote:
Hi,
On Thu, Jan 19, 2012 at 9:32 PM, stephane eranian
eran...@googlemail.com wrote:
On Thu, Jan 19, 2012 at 2:26 PM, Ming Lei ming@canonical.com wrote:
Hi,
On Thu, Jan 19, 2012 at 9:14 PM, Ming Lei ming@canonical.com wrote:
On Thu, Jan 19, 2012 at 8:51 PM, stephane eranian
eran...@googlemail.com wrote:
On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei ming@canonical.com wrote:
Hi,
On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
eran...@googlemail.com wrote:
Hi,
Ok some update on this.
With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a
kernel that
You forget patch 1 and patch 2?
They are already in 3.2.0. Unless I am mistaken.
Sorry, I just found that they have been merged to 3.2.
After a double check, the two patches are not merged to 3.2, but have
been merged to the latest linus tree and can be seen in 3.3-rc1.
Also the commit 3c50729b(ARM: OMAP4: PM: Initialise all the clockdomains
to supported states) has been merged to linus tree too.
So if you just tested the latest linus tree simply, you need to apply
the patch[1]
(I have mentioned the problem in the thread.)
Changing LMO, u-boot.bin did not help. Even with perf top I get no
interrupts.
My Linus tree is at commit fa1952b:
[6] 11891e1 arm: omap4: pmu: support runtime pm
[5] 25fab8a arm: omap4: support pmu
[4] fddef77 arm: omap4: create pmu device via hwmod
fa1952b ARM: OMAP4: hwmod data: Add support for the debug modules
Sorry, there is no commit fa1952b in linus[1] tree at all, so you are
not testing
linus tree...
If you'd like to follow my instructions, I can help you further.
ccb19d2 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
c3b5003 tg3: Fix single-vector MSI-X code
I think [1] had conflicts when applying it to the tree.
It is only one line(one character) change, you can do it manually.
thanks,
--
Ming Lei
[1],
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..41d2260 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_SWSUP,
};
[1], http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary
thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Will and stephane,
On Wed, Jan 18, 2012 at 12:18 PM, Ming Lei ming@canonical.com wrote:
Hi stephane Will,
On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian
eran...@googlemail.com wrote:
See the dmesg from my 3.2 kernel:
[ 0.00] Booting Linux on physical CPU 0[ 0.00]
But if you test omap4 perf against -next kernel, pmu won't work because
the commit[1] may put 'emu_sys_clkdm' clock domain into HW_AUTO mode,
so writing pmu register may not take effect.
I have found the similar problem on cam clock domain before[2].
CD_EMU is very simliar with CD_CAM in the point below:
CD_EMU has no static or module wake-up dependency with any other clock
domain of the device.[3]
So the patch[4] can make omap4 pmu work on -next tree.
Shilimkar, care to comment on the patch[4]?
thanks,
--
Ming Lei
[1], commit 3c50729b3fa1cd8ca1f347e6caf1081204cf1a7c
Author: Santosh Shilimkar santosh.shilim...@ti.com
Date: Wed Jan 5 22:03:17 2011 +0530
ARM: OMAP4: PM: Initialise all the clockdomains to supported states
Initialise hardware supervised mode for all clockdomains if it's
supported. Initiate sleep transition for other clockdomains,
if they are not being used.
[2], http://www.spinics.net/lists/linux-omap/msg61911.html
[3], 3.6.12.3 of OMAP4 TRM
[4],
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..41d2260 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags= CLKDM_CAN_HWSUP,
+ .flags= CLKDM_CAN_SWSUP,
};
static struct clockdomain l3_dma_44xx_clkdm = {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Wed, Jan 18, 2012 at 5:18 AM, Ming Lei ming@canonical.com wrote: Hi stephane Will, On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian eran...@googlemail.com wrote: See the dmesg from my 3.2 kernel: [ 0.00] Booting Linux on physical CPU 0[ 0.00] Looks no obvious failure can be found from your 'dmesg'. I have run upstream 3.2 kernel plus 6 omap4 pmu patches below and found perf can work well on my panda board. 0001-arm-introduce-cross-trigger-interface-helpers.patch 0002-arm-pmu-allow-platform-specific-irq-enable-disable-h.patch 0003-arm-omap4-hwmod-introduce-emu-hwmod.patch or Benoit's debugss patch[2] 0004-arm-omap4-create-pmu-device-via-hwmod.patch[3] 0005-arm-omap4-support-pmu.patch[4] 0006-arm-omap4-pmu-support-runtime-pm.patch[5] Could you verify the above patches on 3.2 to see if perf can work well? If it doesn't, I may share my u-boot and mlo for your test if you'd like to do. BTW: #1 and #2 have been in Will's -next tree. Should I use Will's -next tree as the base instead of Linus'? Given that MARC is shutdown today, would you mind packing those patches into a tarball and sending them to me directly? When you mention Will's -next tree, are you talking about: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf Thanks. thanks, -- Ming Lei [1], uname -a cat /proc/interrupts [root@root]#uname -a Linux beagleboard 3.2.0+ #480 SMP PREEMPT Wed Jan 18 11:38:33 CST 2012 armv7l GNU/Linux [root@root]#cat /proc/interrupts CPU0 CPU1 29: 29014 17353 GIC twd 33: 56231 0 GIC arm-pmu 34: 0 25778 GIC arm-pmu [2], http://marc.info/?l=linux-omapm=132162118104901w=2 [3],http://marc.info/?t=13222762152r=1w=2 [4],http://marc.info/?t=13222762172r=1w=2 [5],http://marc.info/?t=13222762173r=1w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi, On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian eran...@googlemail.com Should I use Will's -next tree as the base instead of Linus'? Either one is OK. If you use linus tree as base, you need to apply the #1 and #2 patch manually. Given that MARC is shutdown today, would you mind packing those patches into a tarball and sending them to me directly? See attachment, which includes the patches from #3 to #6. When you mention Will's -next tree, are you talking about: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf It is perf/omap4 brach, you can pick up the two patches[1][2] directly from the branch. thanks, -- Ming Lei [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f omap4_pmu.tar.gz Description: GNU Zip compressed data
