[PATCH V2 01/10] ARM: PMU: Add runtime PM Support

[Jon Hunter]

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:
>> Hi Will,
> 
> Hello,
> 
>> On 06/11/2012 12:39 PM, Will Deacon wrote:
>>> 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.
> 
>> 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?

>>> 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