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
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
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
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:
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
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
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
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
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.
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
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
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.
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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,
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
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
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
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).
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
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
---
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
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
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
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
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,
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
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
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
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
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
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
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
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
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:
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
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
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,
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
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):
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:
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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 +
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 +
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
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
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
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
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]
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
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
1 - 100 of 110 matches
Mail list logo
