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

Jon Hunter jon-hunter at ti.com
Mon Jun 11 15:01:23 EDT 2012

Hi Will,

On 06/11/2012 12:39 PM, Will Deacon wrote:
> On Fri, Jun 08, 2012 at 04:24:32PM +0100, Jon Hunter wrote:
>> Hi Will,
> Hi Jon,
>> Here is an updated version. I was going to send out a V3, but I wanted
>> to wait to see if others had more comments first.
> 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?

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.

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


More information about the linux-arm-kernel mailing list