From: Krzysztof Kozlowski <krzk@kernel.org>
To: "Yang Jialong 杨佳龙" <jialong.yang@shingroup.cn>,
"Will Deacon" <will@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>
Cc: shenghui.qu@shingroup.cn, ke.zhao@shingroup.cn,
zhijie.ren@shingroup.cn, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] perf/hx_arm_ni: Support uncore ARM NI-700 PMU
Date: Wed, 31 Jan 2024 10:38:39 +0100 [thread overview]
Message-ID: <fef66164-1238-45e4-b70c-c565caa2cf75@kernel.org> (raw)
In-Reply-To: <6D9001324476F76F+ee5f853d-7c69-4a99-857c-cc2b03e9eea1@shingroup.cn>
On 31/01/2024 10:07, Yang Jialong 杨佳龙 wrote:
>
>
> 在 2024/1/31 15:59, Krzysztof Kozlowski 写道:
>> On 31/01/2024 08:08, JiaLong.Yang wrote:
>>> This code is based on uncore PMUs arm_smmuv3_pmu and arm-cmn.
>>> One ni-700 can have many clock domains. Each of them has only one PMU.
>>> Here one PMU corresponds to one 'struct ni_pmu' instance.
>>> PMU name will be ni_pmu_N_M, which N means different NI-700s and M means
>>> different PMU in one NI-700. If only one NI-700 found in NI-700, name will
>>> be ni_pmu_N.
>>> Node interface event name will be xxni_N_eventname, such as
>>> asni_0_rdreq_any. There are many kinds of type of nodes in one clock
>>> domain. Also means that there are many kinds of that in one PMU. So we
>>> distinguish them by xxni string. Besides, maybe there are many nodes
>>> have same type. So we have number N in event name.
>>> By ni_pmu_0_0/asni_0_rdreq_any/, we can pinpoint accurate bus traffic.
>>> Example1: perf stat -a -e ni_pmu_0_0/asni_0_rdreq_any/,ni_pmu_0_0/cycles/
>>> EXample2: perf stat -a -e ni_pmu_0_0/asni,id=0,event=0x0/
>>>
>>> Signed-off-by: JiaLong.Yang <jialong.yang@shingroup.cn>
>>> ---
>>> v1 --> v2:
>>> 1. Submit MAINTANER Documentation/ files seperately.
>>
>> SEPARATE PATCHES, not patchsets. You have now checkpatch warnings
>> because of this...
>
> ...OK. But the MAINTANER file changing should be given in which one
> patches.
> I will submit patch v3 after talking and your permission.
>
>>
>>> 2. Delete some useless info printing.
>>> 3. Change print from pr_xxx to dev_xxx.
>>> 4. Fix more than 75 length log info.
>>> 5. Fix dts attribute pccs-id.
>>> 6. Fix generic name according to DT specification.
>>> 7. Some indentation.
>>> 8. Del of_match_ptr macro.
>>>
>>> drivers/perf/Kconfig | 11 +
>>> drivers/perf/Makefile | 1 +
>>> drivers/perf/hx_arm_ni.c | 1284 ++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 1296 insertions(+)
>>> create mode 100644 drivers/perf/hx_arm_ni.c
>>>
>>> diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
>>> index ec6e0d9194a1..95ef8b13730f 100644
>>> --- a/drivers/perf/Kconfig
>>> +++ b/drivers/perf/Kconfig
>>> @@ -241,4 +241,15 @@ config CXL_PMU
>>>
>>> If unsure say 'm'.
>>>
>>> +config HX_ARM_NI_PMU
>>> + tristate "HX ARM NI-700 PMU"
>>> + depends on PPC_HX_C2000 && 64BIT
>>
>> 1. There is no PPC_HX_C2000.
>
> I have been used to using this macro. However this macro is not existed
> in mainline.
> I will replace it with ARM64. And del involved C code if OK.
>
> 64bit:
> __ffs(unsigned long) and __fls(unsigned long) will be wrong in 32bit. I
> pass a u64 argument.
One thing is where the code is supposed to run, second thing is compile
testing.
Why do you use __ffs, not __ffs64 which takes u64 if you really want
only 64bit argument? unsigned long != u64, so your code is not
architecture independent. You claim you wrote it on purpose as
non-architecture-independent, but then I claim it's a bug. We are
supposed to write code which is portable, as much as possible, assuming
it does not affect readability.
> struct ni_hw_perf_event will be big than limit.
> BUILD_BUG_ON(sizeof(struct ni_hw_perf_event) > offsetof(struct
> hw_perf_event, target));
And why do you need to use any of such code? Please open one of hundreds
of other drivers which work correctly on 32 and 64-bit platforms.
>
>> 2. Nothing justified dependency on 64bit. Drop or explain. Your previous
>> message did not provide real rationale.
>
> If ARM64, then drop.
...
...
>>> + /* Step2: Traverse all clock domains. */
>>> + for (cd_idx = 0; cd_idx < ni->cd_num; cd_idx++) {
>>> + cd = cd_arrays[cd_idx];
>>> +
>>> + num = ni_child_number(cd);
>>> + dev_dbg(dev, "The %dth clock domain has %d child nodes:", cd_idx, num);
>>> +
>>> + /* Omit pmu node */
>>> + ni_pmu = devm_kzalloc(dev, struct_size(ni_pmu, ev_src_nodes, num - 1),
>>> + GFP_KERNEL);
>>> + ni_pmu->ev_src_num = num - 1;
>>> +
>>> + if (!ni_pmu)
>>> + return -ENOMEM;
>>> +
>>> + num_idx = 0;
>>> + for (nd_idx = 0; nd_idx < num; nd_idx++) {
>>> + nd = ni_child_pointer(pbase, cd, nd_idx);
>>> +
>>> + node.base = nd;
>>> + node.node_type = ni_node_node_type(nd);
>>> +
>>> + if (unlikely(ni_node_type(nd) == NI_PMU))
>>> + ni_pmu->pmu_node = node;
>>> + else
>>> + ni_pmu->ev_src_nodes[num_idx++] = node;
>>> + dev_dbg(dev, " name: %s id: %d", ni_node_name[node.type], node.id);
>>> + }
>>> +
>>> + ni_pmu->dev = dev;
>>> + ni_pmu->ni = ni;
>>> + ni->ni_pmus[cd_idx] = ni_pmu;
>>> + }
>>> +
>>> + devm_kfree(dev, cd_arrays);
>>
>> Why? If it is not device-lifetime then allocate with usual way.
>>
>
> No device-lifetime.
> Will allocate in stack.
I was thinking about kzalloc. But if array is small, stack could be as well.
...
>>
>>> +
>>> +static const struct of_device_id ni_pmu_of_match[] = {
>>> + { .compatible = "hx,c2000-arm-ni" },
>>
>> Don't send undocumented compatibles.
>
> OK. Means I should send doc and code in one patch thread with more than
> one patch?
Yes. Please open lore.kernel.org and look at any other submissions
involving bindings or other type of ABI documentation (like sysfs).
Best regards,
Krzysztof
next prev parent reply other threads:[~2024-01-31 9:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-31 7:08 [PATCH v2] perf/hx_arm_ni: Support uncore ARM NI-700 PMU JiaLong.Yang
2024-01-31 7:59 ` Krzysztof Kozlowski
2024-01-31 9:07 ` Yang Jialong 杨佳龙
2024-01-31 9:38 ` Krzysztof Kozlowski [this message]
2024-01-31 10:07 ` Yang Jialong 杨佳龙
2024-01-31 10:36 ` Krzysztof Kozlowski
2024-02-01 3:00 ` Yang Jialong 杨佳龙
[not found] ` <cefbbefe-9b10-4ae4-9bb8-af6eb6916f6a@shingroup.cn>
2024-02-01 6:35 ` Yang Jialong 杨佳龙
2024-01-31 16:50 ` Robin Murphy
2024-02-01 2:40 ` Yang Jialong 杨佳龙
2024-02-02 20:11 ` Robin Murphy
2024-02-29 2:22 ` Yang Jialong 杨佳龙
[not found] ` <fb75eadf-c029-4da7-bda5-300b7d7f51c1@shingroup.cn>
2024-02-29 2:26 ` Yang Jialong 杨佳龙
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=fef66164-1238-45e4-b70c-c565caa2cf75@kernel.org \
--to=krzk@kernel.org \
--cc=jialong.yang@shingroup.cn \
--cc=ke.zhao@shingroup.cn \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=shenghui.qu@shingroup.cn \
--cc=will@kernel.org \
--cc=zhijie.ren@shingroup.cn \
/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