Hi Will,

On 06/12/2012 04:28 AM, Will Deacon wrote:

On Mon, Jun 11, 2012 at 08:01:23PM +0100, Jon Hunter wrote:

quoted

Hi Will,

Hello,

quoted

On 06/11/2012 12:39 PM, Will Deacon wrote:

quoted

This looks better to me, so I took it for a spin on my 4460 (thanks Nicolas!)
and noticed that only the cycle counter seems to tick -- the event counters
always return 0 deltas (that is, they don't increment). Booting the same SD
card on a 4430 (same MLO, u-boot, kernel and filesystem) I see that the
event counters function correctly there.

Thanks for the feedback. Being somewhat new to PMU, I was mainly using
PERF to test and verify that with "perf top" I was seeing interrupts.
How do I check what the event counters are returning? Any perf tests I
could use?

You can continue to use perf top, just specify an event other than cycles:

# perf top -e instructions

for example. You can also use perf stat, but that probably won't be
triggering irqs.

quoted

By the way, as a quick test you could modify the code in omap_init_pmu()
to call omap4430_init_pmu() for all omap4 devices as follows ...

	if (cpu_is_omap44xx())
 		return omap4430_init_pmu();

I was hoping for 4460/70 we would not need to keep the debugss and other
domains on and hence, I called the above function omap4430_init_pmu().
However this function works for all omap4 devices, it just turns on more
power domains.

Well, I tried that and the results are pretty whacky: the event counters do
indeed tick but interrupts only fire if I pin the perf task to CPU1! What's
more, the interrupts do fire on both cores when they're working...

I tried this, and I see that interrupts occur on both, however, it seems
that the majority occur on one CPU and only a few on the other. So it
does appear that one CPU is getting a lot more interrupts.

Without the above change, I can generate cycle counter interrupts regardless
of which CPU I run execute perf.

Yes, I see this to. From more testing, I see that as soon as I turn off
the debugss clock domain "perf top -e instructions" stops working. So I
assume that the event counters are returning 0 in this case.

From a PMU programming standpoint, if we just use "perf top" are the

event counters not used/programmed?

And when we use "perf top -e instructions" is it the "software
increment" event that the event counter(s) are monitoring? I am just
trying to understand how the counters are being programmed and then I
can ask the design folks an intelligent question :-)

By the way, I don't suppose there is any debugfs entry to dump the PMU
registers?

quoted

quoted

It also seems that we can remove the dependency on CONFIG_OMAP3_EMU with these
patches but I don't have any OMAP3 hardware to check if we get any regressions
on older platforms. Do your patches only deal with OMAP4?

It *should* work for all omap2+. So far I have tested an omap3 beagle
but I have not tested an omap2 device. Again the extent of my testing
was to run "perf top" and verify interrupts we being generated. I
realise that this may not be sufficient and so if you have a more
exhaustive test you recommend let me know.

Well, try the above as well as what you're currently doing and that should
test the basics. If that works, I'll happily drop the Kconfig dependency on
OMAP3_EMU (which has been a regular source of confusion).

I still think that there is something I need to understand better here.

Cheers
Jon