From: anurupvasu@gmail•com (Anurup M)
To: linux-arm-kernel@lists•infradead.org
Subject: [RESEND PATCH v1 05/11] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU
Date: Mon, 14 Nov 2016 05:36:44 +0530 [thread overview]
Message-ID: <58290014.2020401@gmail.com> (raw)
In-Reply-To: <20161110183040.GD10137@leverpostej>
On Friday 11 November 2016 12:00 AM, Mark Rutland wrote:
> Hi,
>
> On Thu, Nov 03, 2016 at 01:42:01AM -0400, Anurup M wrote:
>> 1) Device tree bindings for Hisilicon SoC PMU.
>> 2) Add example for Hisilicon L3 cache, MN and DDRC PMU.
>>
>> Signed-off-by: Anurup M<anurup.m@huawei•com>
>> Signed-off-by: Shaokun Zhang<zhangshaokun@hisilicon•com>
>> ---
>> .../devicetree/bindings/arm/hisilicon/pmu.txt | 127 +++++++++++++++++++++
>> 1 file changed, 127 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
>> new file mode 100644
>> index 0000000..e7b35e0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
>> @@ -0,0 +1,127 @@
>> +Hisilicon SoC hip05/06/07 ARMv8 PMU
>> +===================================
>> +
>> +The Hisilicon SoC chips like hip05/06/07 etc. consist of varous independent
>> +system device PMU's such as L3 cache (L3C), Miscellaneous Nodes(MN) and DDR
> s/PMU's/PMUs/
OK.
>> +comtroller. These PMU devices are independent and have hardware logic to
> s/comtroller/controller/
>
>> +gather statistics and performance information.
>> +
>> +HiSilicon SoC chip is encapsulated by multiple CPU and IO die's. The CPU die
> s/die's/dies/
OK.
>> +is called as Super CPU cluster (SCCL) which includes 16 cpu-cores. Every SCCL
>> +is further grouped as CPU clusters (CCL) which includes 4 cpu-cores each.
>> +e.g. In the case of hip05/06/07, each SCCL has 1 L3 cache and 1 MN PMU device.
>> +
>> +The Hisilicon SoC PMU DT node bindigs for uncore PMU devices are as below.
> s/bindigs/bindings/
OK. Thanks. I shall make sure with spell checker before sending v2.
>> +For PMU devices like L3 cache. MN etc. which are accessed using the djtag,
>> +the parent node will be the djtag node of the corresponding CPU die(SCCL).
>> +
>> +For uncore PMU devices there are some common required properties as detailed
>> +below.
>> +
>> +Required properties:
>> + - compatible : This field contain two values. The first value is
>> + always "hisilicon" and second value is the Module type as shown
>> + in below examples:
> Just say:
>
> - Compatible: should contain one of:
OK.
>> + (a) "hisilicon,hisi-pmu-l3c-v1" for Hisilicon SoC L3C PMU
>> + device (Version 1)
>> + (b) "hisilicon,hisi-pmu-mn-v1" for Hisilicon SoC MN PMU
>> + device (Version 1)
>> + (c) "hisilicon,hisi-pmu-ddrc-v1" for Hisilicon SoC DDRC PMU
>> + device (Version 1)
>> + The hip05/06/07 chips have v1 hardware for L3C, MN and DDRC.
>> +
>> + - scl-id : The Super Cluster ID. This can be the ID of the CPU die
>> + or IO die in the chip.
> What's this needed for?
This is used as suffix to the PMU name. hisi_l3c<scl-id>. (hisi_l3c2 -
for scl-id = 2).
This is to identify the pmu correspond to which CPU die in the socket.
>> + - num-events : No of events supported by this PMU device.
>> +
>> + - num-counters : No of hardware counters available for counting.
> This isn't probeable or well-known?
My idea is to have the common properties of SoC PMU added here.
The num-events, num-counters etc. So that handling can be made common in
the driver.
Is it not recommended? Please share your comments.
>> +
>> +L3 cache
>> +--------
>> +The L3 cache is dedicated for each SCCL and hence there are separate DT nodes
>> +for L3 cache for each SCCL. For L3 cache PMU the additional required properties
>> +are
>> + - counter-reg : Counter register offset.
>> +
>> + - evtype-reg : Event select register offset.
>> +
>> + - evctrl-reg : Event counting control(LAUCTRL) register offset.
> Surely for a given revision of the chip these offsets are known? i.e.
> surely the compatible string implies specific offsets?
>
>> + - event-en : Event enable value.
> Huh?
As for the hip05/06 and 07 chips, the above four properties are same, I
shall
move them to the driver.
The below two properties (module-id, cfgen-map) differs between chips
hip05/06 and hip07.
There were moved here so as to have minimal changes in driver across
chips hip05/06/07.
OR whether it is more recommended to have the of_device_id .data set
accordingly for handling
different chip versions?
Please suggest.
>> + - module-id : Module ID to input for djtag. This property is an array of
>> + module_id for each L3 cache banks.
>> +
>> + - num-banks : Number of banks or instances of the device.
> What's a bank? Surely they have separate instances of the PMU?
Yes each bank is a separate instance of PMU.
If it is recommended to have each L3 cache bank registered as separate
PMU with perf, then this property will be removed.
> What order are these in?
The bank number will start from "1" till "4" for L3 cache as there are
four banks in hip05/06/07 chips.
>> + - cfgen-map : Config enable array to select the bank.
> Huh?
>
>> +Miscellaneous Node
>> +-------------------
>> +The MN is dedicated for each SCCL and hence there are separate DT nodes for MN
>> +for each SCCL. For MN PMU the additional required properties are
>> + - counter-reg : Counter register offset.
>> +
>> + - evtype-reg : Event select register offset.
>> +
>> + - evctrl-reg : Event counting control register offset.
> Likewise, surely this is well-known for a given revision of the chip?
>
>> +
>> + - module-id : Module ID to input for djtag. As MN doesnot have multiple banks
>> + this property is a single value.
>> +
>> + - cfgen-map : Config enable to select the bank. For MN it is a single value
>> +
>> + - event-en : Event enable value.
> Same comments as for the L3 cache nodes
>
>
> [...]
>
>> +DDR controller
>> +--------------
>> +Each SCCL in Hip05/06/07 chips have 2 DDR channels and hence 2 DDR controllers.
>> +There are separate DT nodes for each DDR channel.
>> +For DDRC PMU the additional required properties are
>> +
>> + - ch-id : DDRC Channel ID.
> Why is this necessary?
This is used as suffix to the PMU name. hisi_ddrc<scl-id>_<ch-id>.
(hisi_ddrc2_0 - for scl-id = 2, ddrc channel = 0).
This is to identify the pmu correspond to which DDRC channel.
Thanks,
Anurup
> Thanks,
> Mark.
>
>> + - reg : Register base address and range for the DDRC channel.
>> +
>> +Example:
>> + /* DDRC for CPU die scl #2 Channel #1 for hip05 */
>> + pmu_sccl0_ddrc1: pmu_ddrc1 at 80358000 {
>> + compatible = "hisilicon,hisi-pmu-ddrc-v1";
>> + scl-id = <0x02>;
>> + ch-id = <0x1>;
>> + num-events = <0x0D>;
>> + num-counters = <0x04>;
>> + reg = <0x80358000 0x10000>; /* TOTEMC DDRC1 */
>> + };
>> --
>> 2.1.4
>>
next prev parent reply other threads:[~2016-11-14 0:06 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-03 5:41 [RESEND PATCH v1 00/11] perf: arm64: Support for Hisilicon SoC Hardware event counters Anurup M
2016-11-03 5:41 ` [RESEND PATCH v1 01/11] arm64: MAINTAINERS: hisi: Add hisilicon SoC PMU support Anurup M
2016-11-03 5:41 ` [RESEND PATCH v1 02/11] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Sysctrl and Djtag dts bindings Anurup M
2016-11-10 17:23 ` Mark Rutland
2016-11-11 11:19 ` Anurup M
2016-11-11 11:53 ` Mark Rutland
2016-11-11 11:59 ` Anurup M
2016-11-03 5:41 ` [RESEND PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver Anurup M
2016-11-10 17:55 ` Mark Rutland
2016-11-15 10:15 ` Anurup M
2016-11-03 5:42 ` [RESEND PATCH v1 04/11] Documentation: perf: hisi: Documentation for HIP05/06/07 PMU event counting Anurup M
2016-11-03 5:42 ` [RESEND PATCH v1 05/11] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU Anurup M
2016-11-03 18:26 ` Krzysztof Kozlowski
2016-11-04 5:06 ` Anurup M
2016-11-10 18:30 ` Mark Rutland
2016-11-14 0:06 ` Anurup M [this message]
2016-11-15 9:51 ` Mark Rutland
2016-11-16 5:54 ` Anurup M
2016-11-03 5:42 ` [RESEND PATCH v1 06/11] perf: hisi: Update Kconfig for Hisilicon PMU support Anurup M
2016-11-03 5:42 ` [RESEND PATCH v1 07/11] perf: hisi: Add support for Hisilicon SoC event counters Anurup M
2016-11-10 19:10 ` Mark Rutland
2016-11-14 8:11 ` Anurup M
2016-11-03 5:42 ` [RESEND PATCH v1 08/11] perf: hisi: Add sysfs attributes for L3 cache(L3C) PMU Anurup M
2016-11-03 5:42 ` [RESEND PATCH v1 09/11] perf: hisi: Miscellanous node(MN) event counting in perf Anurup M
2016-11-03 5:42 ` [RESEND PATCH v1 10/11] perf: hisi: Support for Hisilicon DDRC PMU Anurup M
2016-11-03 5:42 ` [RESEND 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=58290014.2020401@gmail.com \
--to=anurupvasu@gmail$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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