linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Jon Hunter <jon-hunter@ti.com>
Cc: Kevin Hilman <khilman@ti.com>, Paul Walmsley <paul@pwsan.com>,
	Benoit Cousson <b-cousson@ti.com>,
	Ming Lei <ming.lei@canonical.com>,
	linux-omap <linux-omap@vger.kernel.org>,
	linux-arm <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH V2 01/10] ARM: PMU: Add runtime PM Support
Date: Tue, 12 Jun 2012 22:31:50 +0100	[thread overview]
Message-ID: <20120612213150.GC24380@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <4FD7B1DC.30108@ti.com>

On Tue, Jun 12, 2012 at 10:17:16PM +0100, Jon Hunter wrote:
> Hi Will,

Hi Jon,

> On 06/12/2012 04:28 AM, Will Deacon wrote:
> > 
> > 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.

That's understandable -- one of the CPUs is likely more loaded than the
other. However, I'd like to confirm whether or not you see what I see. With
the 4430_init hack on a 4460, if I run:

# taskset 0x2 perf top

then I get no samples. If I do:

# taskset 0x1 perf top

then I *do* get samples and from *both* CPUs. So it smells more like an
issue poking some configuration registers from CPU1 rather than the IRQ
path being broken. As I said before, if I don't do the extra init hack
then I don't get this problem (but event counters don't tick).

> From a PMU programming standpoint, if we just use "perf top" are the
> event counters not used/programmed?

Just using perf top should use the cycle counter as the event source.

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

It depends on the CPU. For Cortex-A9, `instructions' maps to event 0x68,
which isn't a perfect match. If you want to specify a hex value for the
event code, you can do:

# perf top -e rNN

where NN is the hex event number. On A9, r11 would give you cycles via
an event counter.

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

'fraid not, but there is some debug code in perf_event_v7.c that you
could call if you wanted to (just #define DEBUG at the top of the file).

Will

  reply	other threads:[~2012-06-12 21:32 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-07 21:22 [PATCH V2 00/10] ARM: OMAP4: Add PMU Support Jon Hunter
2012-06-07 21:22 ` [PATCH V2 01/10] ARM: PMU: Add runtime PM Support Jon Hunter
2012-06-08  9:47   ` Will Deacon
2012-06-08 14:17     ` Jon Hunter
2012-06-08 15:24     ` Jon Hunter
2012-06-11 17:39       ` Will Deacon
2012-06-11 19:01         ` Jon Hunter
2012-06-12  9:28           ` Will Deacon
2012-06-12 21:17             ` Jon Hunter
2012-06-12 21:31               ` Will Deacon [this message]
2012-06-12 22:41                 ` Jon Hunter
2012-07-02  9:55                   ` Will Deacon
2012-07-02 16:50                     ` Jon Hunter
2012-07-02 22:01                       ` Will Deacon
2012-07-06  0:40                         ` Jon Hunter
2012-07-26  0:41                           ` Jon Hunter
2012-07-26 15:05                             ` Will Deacon
2012-07-26 15:16                               ` Jon Hunter
2012-07-31 15:14                                 ` Will Deacon
2012-07-31 23:07                                   ` Jon Hunter
2012-08-01 20:47                                     ` Will Deacon
2012-08-01 22:34                                       ` Jon Hunter
2012-06-07 21:22 ` [PATCH V2 02/10] ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD Jon Hunter
2012-06-07 21:22 ` [PATCH V2 03/10] ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS Jon Hunter
2012-06-13  6:07   ` Pandita, Vikram
2012-06-13  6:13     ` Pandita, Vikram
2012-06-13  6:19       ` Shilimkar, Santosh
2012-06-07 21:22 ` [PATCH V2 04/10] ARM: OMAP4430: Create PMU device via HWMOD Jon Hunter
2012-06-07 21:22 ` [PATCH V2 05/10] ARM: OMAP2+: PMU: Add runtime PM support Jon Hunter
2012-06-07 21:22 ` [PATCH V2 06/10] ARM: OMAP4: Route PMU IRQs to CTI IRQs Jon Hunter
2012-06-07 21:22 ` [PATCH V2 07/10] ARM: OMAP4: CLKDM: Update supported transition modes Jon Hunter
2012-07-04 15:38   ` Paul Walmsley
2012-07-05 17:14     ` Jon Hunter
2012-06-07 21:22 ` [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use Jon Hunter
2012-07-12 21:17   ` Paul Walmsley
2012-07-13 13:54     ` Jon Hunter
2012-07-13 14:00       ` Will Deacon
2012-07-13 14:07         ` Jon Hunter
2012-07-20 22:24         ` Jon Hunter
2012-07-13 21:00       ` Paul Walmsley
2012-07-16 18:27         ` Jon Hunter
2012-07-16 18:38           ` Paul Walmsley
2012-07-16 19:38             ` Jon Hunter
2012-07-20 22:24             ` Jon Hunter
2012-07-30 23:26             ` Jon Hunter
2012-07-31  4:36               ` Jon Hunter
2012-07-31 18:16                 ` Jon Hunter
2012-08-01  0:20                   ` Jon Hunter
2012-08-01 15:08                     ` Paul Walmsley
2012-08-01 18:17                       ` Jon Hunter
2012-08-01 15:36                     ` Paul Walmsley
2012-08-01 19:41                       ` Jon Hunter
2012-08-02  7:34                       ` Shilimkar, Santosh
2012-10-08 22:24                       ` Jon Hunter
2012-10-09  4:41                         ` Paul Walmsley
2012-07-31 20:56     ` Jon Hunter
2012-06-07 21:22 ` [PATCH V2 09/10] ARM: OMAP4: Enable PMU for OMAP4460/70 Jon Hunter
2012-06-07 21:22 ` [PATCH V2 10/10] ARM: OMAP2+: PMU: Add QoS constraint Jon Hunter
2012-06-07 23:36 ` [PATCH V2 00/10] ARM: OMAP4: Add PMU Support Jon Hunter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120612213150.GC24380@mudshark.cambridge.arm.com \
    --to=will.deacon@arm.com \
    --cc=b-cousson@ti.com \
    --cc=jon-hunter@ti.com \
    --cc=khilman@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=ming.lei@canonical.com \
    --cc=paul@pwsan.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).