From: Anurup M <anurupvasu@gmail.com>
To: John Garry <john.garry@huawei.com>, Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org, anurup.m@huawei.com,
linux-kernel@vger.kernel.org, mark.rutland@arm.com,
shyju.pv@huawei.com, gabriele.paoloni@huawei.com,
will.deacon@arm.com, linuxarm@huawei.com, xuwei5@hisilicon.com,
zhangshaokun@hisilicon.com, sanil.kumar@hisilicon.com,
tanxiaojun@huawei.com, shiju.jose@huawei.com
Subject: Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver
Date: Fri, 11 Nov 2016 16:05:02 +0530 [thread overview]
Message-ID: <58259ED6.30609@gmail.com> (raw)
In-Reply-To: <d009dcdc-2258-ed6a-53be-2211c7493051@huawei.com>
On Wednesday 09 November 2016 02:36 PM, John Garry wrote:
>
>>>>> I'd suggest requiring #address-cells=<1> and #size-cells=<0> in the
>>>>> master
>>>>> node, and listing the children by reg property. If the address is not
>>>>> easily expressed as a single integer, use a larger #address-cells
>>>>> value.
>>>> We already have something equivalent to reg in "module-id" (see patch
>>>> 02/11), which is the slave device bus address; here's a sample:
>>>> + /* For L3 cache PMU */
>>>> + pmul3c0 {
>>>> + compatible = "hisilicon,hisi-pmu-l3c-v1";
>>>> + scl-id = <0x02>;
>>>> + num-events = <0x16>;
>>>> + num-counters = <0x08>;
>>>> + module-id = <0x04>;
>>>> + num-banks = <0x04>;
>>>> + cfgen-map = <0x02 0x04 0x01 0x08>;
>>>> + counter-reg = <0x170>;
>>>> + evctrl-reg = <0x04>;
>>>> + event-en = <0x1000000>;
>>>> + evtype-reg = <0x140>;
>>>> + };
>>>>
>>>> FYI, "module-id" is our own internal hw nomenclature.
>>> Yes, that was my interpretation as well. Please use the standard
>>> "reg" property for this then.
>> Hi Arnd,
>>
>> Firstly my apologies for a mistake in the bindings example in ([PATCH
>> 02/11 ..]).
>> The module-id property is a list as defined in the PMU bindings patch
>> ([PATCH v1 05/11] dt-bindings .. <https://lkml.org/lkml/2016/11/2/323>).
>>
>> + djtag0: djtag@0 {
>> + compatible = "hisilicon,hip05-cpu-djtag-v1";
>> + pmul3c0 {
>> + compatible = "hisilicon,hisi-pmu-l3c-v1";
>> + scl-id = <0x02>;
>> + num-events = <0x16>;
>> + num-counters = <0x08>;
>> + module-id = <0x04 0x04 0x04 0x04>;
>> + num-banks = <0x04>;
>> + cfgen-map = <0x02 0x04 0x01 0x08>;
>> + counter-reg = <0x170>;
>> + evctrl-reg = <0x04>;
>> + event-en = <0x1000000>;
>> + evtype-reg = <0x140>;
>> + };
>>
>>
>> The L3 cache in hip05/06/07 chips consist of 4 banks (each bank has PMU
>> registers).
>>
>> In hip05/06 all L3 cache banks are identified with same module-id.
>> module-id = <0x04 0x04 0x04 0x04>;
>>
>> But in the case hip07 chip(djtag v2), each L3 cache bank has different
>> module-id
>> module-id = <0x01 0x02 0x03 0x04>;
>>
>> So in this case Please share your opinion on how to model it.
>>
>
> My suggestion is to have a single PMU per module, whether that is 4
> banks or 1 bank per module, as this makes the driver simpler.
>
> I think you mentioned that a separate PMU per bank does not make much
> sense, and you would rather treat all banks as a single bank and
> aggregrate their perf statstics under a single PMU: Can you just use a
> script in userspace which can do this aggregration work if you have
> separate PMUs?
Hi John,
Mark also suggest the same view.
I have some concerns or doubts in having separate PMU for each L3 cache
bank.
We can discuss it in the same thread [[RESEND PATCH v1 07/11]]
<http://www.spinics.net/lists/arm-kernel/msg541938.html>].
Thanks,
Anurup
>
> Maybe perf guys have a view on this also.
>
> John
>
>> Some more detail of L3 cache PMU.
>> ------------------------------------------------
>> The hip05/06/07 chips consists of a multiple Super CPU cluster (16 CPU
>> cores). we call it SCCL.
>> The L3 cache( 4 banks) is shared by all CPU cores in a SCCL.
>> Each L3 cache bank has PMU registers. We always take the sum of the
>> counters to show in perf.
>> Taking individual L3 cache count is not meaningful as there is no
>> mapping of CPU cores to individual
>> L3 cache banks.
>>
>> Please share your suggestion.
>>
>> Thanks,
>> Anurup
>
next prev parent reply other threads:[~2016-11-11 10:35 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-02 15:42 [PATCH v1 00/11] perf: arm64: Support for Hisilicon SoC Hardware event counters Anurup M
2016-11-02 15:42 ` [PATCH v1 01/11] arm64: MAINTAINERS: hisi: Add hisilicon SoC PMU support Anurup M
2016-11-02 15:42 ` [PATCH v1 02/11] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Sysctrl and Djtag dts bindings Anurup M
2016-11-02 15:42 ` [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver Anurup M
2016-11-03 1:59 ` kbuild test robot
2016-11-07 13:26 ` Arnd Bergmann
2016-11-07 14:15 ` John Garry
2016-11-07 20:08 ` Arnd Bergmann
2016-11-08 11:23 ` John Garry
2016-11-08 11:45 ` Arnd Bergmann
2016-11-08 13:49 ` John Garry
2016-11-08 15:10 ` Arnd Bergmann
2016-11-08 15:17 ` John Garry
2016-11-09 10:44 ` Anurup M
2016-11-08 15:51 ` Anurup M
2016-11-09 9:06 ` John Garry
2016-11-11 10:35 ` Anurup M [this message]
2016-11-08 7:02 ` Tan Xiaojun
2016-11-08 7:38 ` Anurup M
2016-11-08 11:43 ` Arnd Bergmann
2016-11-08 13:46 ` Anurup M
2016-11-08 15:08 ` Arnd Bergmann
2016-11-09 4:28 ` Anurup M
2016-11-09 21:40 ` Arnd Bergmann
2016-11-11 10:23 ` Anurup M
2016-11-02 15:42 ` [PATCH v1 04/11] Documentation: perf: hisi: Documentation for HIP05/06/07 PMU event counting Anurup M
2016-11-02 15:42 ` [PATCH v1 05/11] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU Anurup M
2016-11-02 15:42 ` [PATCH v1 06/11] perf: hisi: Update Kconfig for Hisilicon PMU support Anurup M
2016-11-02 15:42 ` [PATCH v1 07/11] perf: hisi: Add support for Hisilicon SoC event counters Anurup M
2016-11-02 15:42 ` [PATCH v1 08/11] perf: hisi: Add sysfs attributes for L3 cache(L3C) PMU Anurup M
2016-11-02 15:42 ` [PATCH v1 09/11] perf: hisi: Miscellanous node(MN) event counting in perf Anurup M
2016-11-02 15:42 ` [PATCH v1 10/11] perf: hisi: Support for Hisilicon DDRC PMU Anurup M
2016-11-02 15:42 ` [PATCH v1 11/11] dts: arm64: hip06: Add Hisilicon SoC PMU support Anurup M
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=58259ED6.30609@gmail.com \
--to=anurupvasu@gmail.com \
--cc=anurup.m@huawei.com \
--cc=arnd@arndb.de \
--cc=gabriele.paoloni@huawei.com \
--cc=john.garry@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=mark.rutland@arm.com \
--cc=sanil.kumar@hisilicon.com \
--cc=shiju.jose@huawei.com \
--cc=shyju.pv@huawei.com \
--cc=tanxiaojun@huawei.com \
--cc=will.deacon@arm.com \
--cc=xuwei5@hisilicon.com \
--cc=zhangshaokun@hisilicon.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).