From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] drivers: CCI: add ARM CCI PMU support
Date: Fri, 16 Aug 2013 12:31:57 -0600 [thread overview]
Message-ID: <520E701D.6040006@wwwdotorg.org> (raw)
In-Reply-To: <1376673599-3967-1-git-send-email-punit.agrawal@arm.com>
On 08/16/2013 11:19 AM, Punit Agrawal wrote:
> The CCI PMU can profile bus transactions at the master and slave
> interfaces of the CCI. The PMU can be used to observe an aggregated view
> of the bus traffic between the various components connected to the CCI.
>
> Extend the existing CCI driver to support the PMU by registering a perf
> backend for it.
I think this binding addresses my comments, thanks. Just one comment below:
> diff --git a/Documentation/devicetree/bindings/arm/cci.txt b/Documentation/devicetree/bindings/arm/cci.txt
> + - reg:
> + Usage: required
> + Value type: <prop-encoded-array>
> + - interrupts:
> + Usage: required
> + Value type: <prop-encoded-array>
That makes it sound like the layout/content of those two properties is
the same. That's not true; one is an array of (base, size) cells, and
the other is of (phandle, args*) cells. The difference between the data
being phandles-vs-integers seems important.
Perhaps says:
Value type: Integer cells. Array of register entries, each expressed as
a pair of cells, containing base and size.
Value type: Integer cells. Array of interrupt specifier entries, as
defined in ../interrupt-controller/interupts.txt.
> + Definition: comma-separated list of counter overflow
Oh, and lists of cells aren't necessarily comma-separated; comma is used
between <> but not inside <>, and there's no requirement that each
individual interrupt specifier be in its own <>, vs. just aggregating
all of them into a single <>.
next prev parent reply other threads:[~2013-08-16 18:31 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-11 3:00 [PATCH] drivers: CCI: add ARM CCI PMU support Punit Agrawal
2013-08-05 11:37 ` Punit Agrawal
2013-08-07 1:45 ` Will Deacon
2013-08-12 13:59 ` Will Deacon
2013-08-12 16:08 ` Will Deacon
2013-08-12 16:58 ` Punit Agrawal
2013-08-14 21:03 ` Kumar Gala
2013-08-14 22:38 ` Rob Herring
2013-08-15 10:01 ` Punit Agrawal
2013-08-15 9:10 ` Punit Agrawal
2013-08-15 16:25 ` Kumar Gala
2013-08-16 10:31 ` Punit Agrawal
2013-08-16 10:53 ` Kumar Gala
2013-08-15 19:00 ` Kumar Gala
2013-08-16 10:56 ` Punit Agrawal
2013-08-16 11:31 ` Kumar Gala
2013-08-16 12:41 ` Punit Agrawal
2013-08-14 21:06 ` Stephen Warren
2013-08-14 21:09 ` Kumar Gala
2013-08-14 21:13 ` Stephen Warren
2013-08-14 21:16 ` Kumar Gala
2013-08-15 10:09 ` Punit Agrawal
2013-08-16 17:19 ` [PATCH v2] " Punit Agrawal
2013-08-16 18:31 ` Stephen Warren [this message]
2013-08-19 11:14 ` Punit Agrawal
2013-08-19 16:15 ` Stephen Warren
2013-08-16 18:47 ` Kumar Gala
2013-08-19 11:21 ` Punit Agrawal
2013-08-20 15:07 ` Will Deacon
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=520E701D.6040006@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.