On 2023/11/8 4:28, Uwe Kleine-König wrote:
> If smb_config_inport() fails it's still necessary to unregister all
> resources. As smb_config_inport() already emits an error message on
> failure, there is no need to add another one. By not returning the error
> code, a second error message (about the return value being ignored) is
> suppressed.
>
> Fixes: 06f5c2926aaa ("drivers/coresight: Add UltraSoc System Memory Buffer driver")
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de>
Hi,
thanks, for the report. Can you try this patch and help review it?
https://lore.kernel.org/linux-arm-kernel/20231021083822.18239-3-hejunhao3@h…
This patch should have fixed this issue.
Best regards,
Junhao.
> ---
> drivers/hwtracing/coresight/ultrasoc-smb.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/ultrasoc-smb.c b/drivers/hwtracing/coresight/ultrasoc-smb.c
> index e9a32a97fbee..10e7d4852112 100644
> --- a/drivers/hwtracing/coresight/ultrasoc-smb.c
> +++ b/drivers/hwtracing/coresight/ultrasoc-smb.c
> @@ -613,11 +613,8 @@ static int smb_probe(struct platform_device *pdev)
> static int smb_remove(struct platform_device *pdev)
> {
> struct smb_drv_data *drvdata = platform_get_drvdata(pdev);
> - int ret;
>
> - ret = smb_config_inport(&pdev->dev, false);
> - if (ret)
> - return ret;
> + smb_config_inport(&pdev->dev, false);
>
> smb_unregister_sink(drvdata);
>
Em Tue, Nov 07, 2023 at 12:08:25PM +0530, Athira Rajeev escreveu:
> > On 07-Nov-2023, at 3:14 AM, Arnaldo Carvalho de Melo <acme(a)kernel.org> wrote:
> >>> Reviewed-by: James Clark <james.clark(a)arm.com>
> > Some are not applying, even after b4 picking up v2
> > Total patches: 3
> > Cover: ./v2_20231013_atrajeev_fix_for_shellcheck_issues_with_latest_scripts_in_tests_shell.cover
> > Link: https://lore.kernel.org/r/20231013073021.99794-1-atrajeev@linux.vnet.ibm.com
> > Base: not specified
> > git am ./v2_20231013_atrajeev_fix_for_shellcheck_issues_with_latest_scripts_in_tests_shell.mbx
> > ⬢[acme@toolbox perf-tools-next]$ git am ./v2_20231013_atrajeev_fix_for_shellcheck_issues_with_latest_scripts_in_tests_shell.mbx
> > Applying: tools/perf/tests Ignore the shellcheck SC2046 warning in lock_contention
> > error: patch failed: tools/perf/tests/shell/lock_contention.sh:33
> > error: tools/perf/tests/shell/lock_contention.sh: patch does not apply
> > Patch failed at 0001 tools/perf/tests Ignore the shellcheck SC2046 warning in lock_contention
> > hint: Use 'git am --show-current-patch=diff' to see the failed patch
> > When you have resolved this problem, run "git am --continue".
> > If you prefer to skip this patch, run "git am --skip" instead.
> > To restore the original branch and stop patching, run "git am --abort".
> > ⬢[acme@toolbox perf-tools-next]$ git am --abort
> > ⬢[acme@toolbox perf-tools-next]$
> The patch is picked up : https://lore.kernel.org/all/169757198796.167943.10552920255799914362.b4-ty@… .
> Thanks for looking into.
Thanks for checking, my mistake then,
- Arnaldo
On 10/27/2023 5:25 AM, Rob Herring wrote:
> On Wed, Oct 25, 2023 at 10:53:21AM +0800, Tao Zhang wrote:
>> Add property "qcom,cmb-elem-size" to support CMB(Continuous
>> Multi-Bit) element for TPDM. The associated aggregator will read
>> this size before it is enabled. CMB element size currently only
>> supports 32-bit and 64-bit.
>>
>> Signed-off-by: Tao Zhang <quic_taozha(a)quicinc.com>
>> Signed-off-by: Mao Jinlong <quic_jinlmao(a)quicinc.com>
>> ---
>> .../bindings/arm/qcom,coresight-tpdm.yaml | 27 ++++++++++++++++++++++
>> 1 file changed, 27 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
>> index 61ddc3b..f9a2025 100644
>> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml
>> @@ -52,6 +52,14 @@ properties:
>> $ref: /schemas/types.yaml#/definitions/uint8
>> enum: [32, 64]
>>
>> + qcom,cmb-element-size:
> What are the units? Use '-bits' suffix.
Yes, its unit should be bit.
Do you mean that you prefer to use "qcom, cmb-element-size-bits"?
Do I also need to replace "qcom, dsb-element-size" with "qcom,
dsb-element-size-bits".
>
>> + description:
>> + Specifies the CMB(Continuous Multi-Bit) element size supported by
>> + the monitor. The associated aggregator will read this size before it
>> + is enabled. CMB element size currently only supports 32-bit and 64-bit.
> The enum says 8-bit is supported.
Yes, 8-bit is supported. I will update the description in the next patch
series.
Best,
Tao
>
>> + $ref: /schemas/types.yaml#/definitions/uint8
>> + enum: [8, 32, 64]
>> +
>> qcom,dsb-msrs-num:
>> description:
>> Specifies the number of DSB(Discrete Single Bit) MSR(mux select register)
>> @@ -110,4 +118,23 @@ examples:
>> };
>> };
>>
>> + tpdm@6c29000 {
>> + compatible = "qcom,coresight-tpdm", "arm,primecell";
>> + reg = <0x06c29000 0x1000>;
>> + reg-names = "tpdm-base";
>> +
>> + qcom,cmb-element-size = /bits/ 8 <64>;
>> +
>> + clocks = <&aoss_qmp>;
>> + clock-names = "apb_pclk";
>> +
>> + out-ports {
>> + port {
>> + tpdm_ipcc_out_funnel_center: endpoint {
>> + remote-endpoint =
>> + <&funnel_center_in_tpdm_ipcc>;
>> + };
>> + };
>> + };
>> + };
>> ...
>> --
>> 2.7.4
>>
Hi Adrian,
On Tue, Nov 07, 2023 at 09:19:10AM +0200, Adrian Hunter wrote:
> On 6/11/23 23:52, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Oct 19, 2023 at 01:47:15PM +0300, Adrian Hunter escreveu:
> >> On 14/10/23 10:45, Leo Yan wrote:
> >>> An AUX trace can contain timestamp, but in some situations, the hardware
> >>> trace module (e.g. Arm CoreSight) cannot decide the traced timestamp is
> >>> the same source with CPU's time, thus the decoder can not use the
> >>> timestamp trace for samples.
> >>>
> >>> This patch introduces 'T' itrace option. If users know the platforms
> >>
> >> "If users know" <- how would users know? Could the kernel
> >> or tools also figure it out?
> >
> > Adrian, I'm trying to go all the outstanding patches, do you still have
> > any issues with this series?
>
> No, although the question wasn't actually answered. I presume users
> just have to try the 'T' option and see if it helps.
Sometimes, users are software developers in SoC companies, they can
know well for the hardware design but are confused why current
implementation cannot use timestamp trace. This is the main reason
I sent this patch set.
An example hardware platform is DB410c [1], we know its CoreSight can
support timestamp trace, but if without this adding option 'T', we
have no chance to use it due to it its CPU arch is prior to Armv8.4.
@Arnaldo, since James gave comments in his replying, I will respin new
patch set and send out. Thanks for popping up this patch set!
Leo
[1] https://developer.qualcomm.com/hardware/dragonboard-410c
On 07/11/2023 07:19, Adrian Hunter wrote:
> On 6/11/23 23:52, Arnaldo Carvalho de Melo wrote:
>> Em Thu, Oct 19, 2023 at 01:47:15PM +0300, Adrian Hunter escreveu:
>>> On 14/10/23 10:45, Leo Yan wrote:
>>>> An AUX trace can contain timestamp, but in some situations, the hardware
>>>> trace module (e.g. Arm CoreSight) cannot decide the traced timestamp is
>>>> the same source with CPU's time, thus the decoder can not use the
>>>> timestamp trace for samples.
>>>>
>>>> This patch introduces 'T' itrace option. If users know the platforms
>>>
>>> "If users know" <- how would users know? Could the kernel
>>> or tools also figure it out?
>>
>> Adrian, I'm trying to go all the outstanding patches, do you still have
>> any issues with this series?
>
> No, although the question wasn't actually answered. I presume users
> just have to try the 'T' option and see if it helps.
>
I suppose my previous answer about discoverability was more general. To
answer the specific question "how would users know?", it would have to
be mentioned in the reference manual of their device that this is how
the timers are set up.
But I don't see this being a common use case, as I mentioned before, in
newer arm platforms this is discoverable and just works.
Em Thu, Oct 19, 2023 at 01:47:15PM +0300, Adrian Hunter escreveu:
> On 14/10/23 10:45, Leo Yan wrote:
> > An AUX trace can contain timestamp, but in some situations, the hardware
> > trace module (e.g. Arm CoreSight) cannot decide the traced timestamp is
> > the same source with CPU's time, thus the decoder can not use the
> > timestamp trace for samples.
> >
> > This patch introduces 'T' itrace option. If users know the platforms
>
> "If users know" <- how would users know? Could the kernel
> or tools also figure it out?
Adrian, I'm trying to go all the outstanding patches, do you still have
any issues with this series?
- Arnaldo
> > they are working on have the same time counter with CPUs, users can
> > use this new option to tell a decoder for using timestamp trace as
> > kernel time.
> >
> > Signed-off-by: Leo Yan <leo.yan(a)linaro.org>
> > ---
> > tools/perf/Documentation/itrace.txt | 1 +
> > tools/perf/util/auxtrace.c | 3 +++
> > tools/perf/util/auxtrace.h | 3 +++
> > 3 files changed, 7 insertions(+)
> >
> > diff --git a/tools/perf/Documentation/itrace.txt b/tools/perf/Documentation/itrace.txt
> > index a97f95825b14..19cc179be9a7 100644
> > --- a/tools/perf/Documentation/itrace.txt
> > +++ b/tools/perf/Documentation/itrace.txt
> > @@ -25,6 +25,7 @@
> > q quicker (less detailed) decoding
> > A approximate IPC
> > Z prefer to ignore timestamps (so-called "timeless" decoding)
> > + T use the timestamp trace as kernel time
> >
> > The default is all events i.e. the same as --itrace=iybxwpe,
> > except for perf script where it is --itrace=ce
> > diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c
> > index a0368202a746..f528c4364d23 100644
> > --- a/tools/perf/util/auxtrace.c
> > +++ b/tools/perf/util/auxtrace.c
> > @@ -1638,6 +1638,9 @@ int itrace_do_parse_synth_opts(struct itrace_synth_opts *synth_opts,
> > case 'Z':
> > synth_opts->timeless_decoding = true;
> > break;
> > + case 'T':
> > + synth_opts->use_timestamp = true;
> > + break;
> > case ' ':
> > case ',':
> > break;
> > diff --git a/tools/perf/util/auxtrace.h b/tools/perf/util/auxtrace.h
> > index 29eb82dff574..55702215a82d 100644
> > --- a/tools/perf/util/auxtrace.h
> > +++ b/tools/perf/util/auxtrace.h
> > @@ -99,6 +99,7 @@ enum itrace_period_type {
> > * @remote_access: whether to synthesize remote access events
> > * @mem: whether to synthesize memory events
> > * @timeless_decoding: prefer "timeless" decoding i.e. ignore timestamps
> > + * @use_timestamp: use the timestamp trace as kernel time
> > * @vm_time_correlation: perform VM Time Correlation
> > * @vm_tm_corr_dry_run: VM Time Correlation dry-run
> > * @vm_tm_corr_args: VM Time Correlation implementation-specific arguments
> > @@ -146,6 +147,7 @@ struct itrace_synth_opts {
> > bool remote_access;
> > bool mem;
> > bool timeless_decoding;
> > + bool use_timestamp;
> > bool vm_time_correlation;
> > bool vm_tm_corr_dry_run;
> > char *vm_tm_corr_args;
> > @@ -678,6 +680,7 @@ bool auxtrace__evsel_is_auxtrace(struct perf_session *session,
> > " q: quicker (less detailed) decoding\n" \
> > " A: approximate IPC\n" \
> > " Z: prefer to ignore timestamps (so-called \"timeless\" decoding)\n" \
> > +" T: use the timestamp trace as kernel time\n" \
> > " PERIOD[ns|us|ms|i|t]: specify period to sample stream\n" \
> > " concatenate multiple options. Default is iybxwpe or cewp\n"
> >
>
--
- Arnaldo
Em Thu, Oct 05, 2023 at 02:24:15PM +0530, Athira Rajeev escreveu:
> > On 05-Oct-2023, at 1:50 PM, James Clark <james.clark(a)arm.com> wrote:
> > On 29/09/2023 05:11, Athira Rajeev wrote:
> >> Running shellcheck on tests/shell/test_arm_coresight.sh
> >> throws below warnings:
> >>
> >> In tests/shell/test_arm_coresight.sh line 15:
> >> cs_etm_path=$(find /sys/bus/event_source/devices/cs_etm/ -name cpu* -print -quit)
> >> ^--^ SC2061: Quote the parameter to -name so the shell won't interpret it.
> >>
> >> In tests/shell/test_arm_coresight.sh line 20:
> >> if [ $archhver -eq 5 -a "$(printf "0x%X\n" $archpart)" = "0xA13" ] ; then
> >> ^-- SC2166: Prefer [ p ] && [ q ] as [ p -a q ] is not well defined
> >>
> >> This warning is observed after commit:
> >> "commit bb350847965d ("perf test: Update cs_etm testcase for Arm ETE")"
> >>
> >> Fixed this issue by using quoting 'cpu*' for SC2061 and
> >> using "&&" in line number 20 for SC2166 warning
> >>
> >> Fixes: bb350847965d ("perf test: Update cs_etm testcase for Arm ETE")
> >> Signed-off-by: Athira Rajeev <atrajeev(a)linux.vnet.ibm.com>
> >> ---
> >> tools/perf/tests/shell/test_arm_coresight.sh | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/tools/perf/tests/shell/test_arm_coresight.sh b/tools/perf/tests/shell/test_arm_coresight.sh
> >> index fe78c4626e45..f2115dfa24a5 100755
> >> --- a/tools/perf/tests/shell/test_arm_coresight.sh
> >> +++ b/tools/perf/tests/shell/test_arm_coresight.sh
> >> @@ -12,12 +12,12 @@
> >> glb_err=0
> >>
> >> cs_etm_dev_name() {
> >> - cs_etm_path=$(find /sys/bus/event_source/devices/cs_etm/ -name cpu* -print -quit)
> >> + cs_etm_path=$(find /sys/bus/event_source/devices/cs_etm/ -name 'cpu*' -print -quit)
> >> trcdevarch=$(cat ${cs_etm_path}/mgmt/trcdevarch)
> >> archhver=$((($trcdevarch >> 12) & 0xf))
> >> archpart=$(($trcdevarch & 0xfff))
> >>
> >> - if [ $archhver -eq 5 -a "$(printf "0x%X\n" $archpart)" = "0xA13" ] ; then
> >> + if [ $archhver -eq 5 ] && [ "$(printf "0x%X\n" $archpart)" = "0xA13" ] ; then
> >> echo "ete"
> >> else
> >> echo "etm"
> >
> >
> > Reviewed-by: James Clark <james.clark(a)arm.com>
Some are not applying, even after b4 picking up v2
Total patches: 3
---
Cover: ./v2_20231013_atrajeev_fix_for_shellcheck_issues_with_latest_scripts_in_tests_shell.cover
Link: https://lore.kernel.org/r/20231013073021.99794-1-atrajeev@linux.vnet.ibm.com
Base: not specified
git am ./v2_20231013_atrajeev_fix_for_shellcheck_issues_with_latest_scripts_in_tests_shell.mbx
⬢[acme@toolbox perf-tools-next]$ git am ./v2_20231013_atrajeev_fix_for_shellcheck_issues_with_latest_scripts_in_tests_shell.mbx
Applying: tools/perf/tests Ignore the shellcheck SC2046 warning in lock_contention
error: patch failed: tools/perf/tests/shell/lock_contention.sh:33
error: tools/perf/tests/shell/lock_contention.sh: patch does not apply
Patch failed at 0001 tools/perf/tests Ignore the shellcheck SC2046 warning in lock_contention
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
⬢[acme@toolbox perf-tools-next]$ git am --abort
⬢[acme@toolbox perf-tools-next]$
CCITMIN is a 12 bit field and doesn't fit in a u8, so extend it to u16.
This probably wasn't an issue previously because values higher than 255
never occurred.
But since commit 0f55b43dedcd ("coresight: etm: Override TRCIDR3.CCITMIN
on errata affected cpus"), a comparison with 256 was done to enable the
errata, generating the following W=1 build error:
coresight-etm4x-core.c:1188:24: error: result of comparison of
constant 256 with expression of type 'u8' (aka 'unsigned char') is
always false [-Werror,-Wtautological-constant-out-of-range-compare]
if (drvdata->ccitmin == 256)
Cc: stable(a)vger.kernel.org
Fixes: 54ff892b76c6 ("coresight: etm4x: splitting struct etmv4_drvdata")
Signed-off-by: James Clark <james.clark(a)arm.com>
---
drivers/hwtracing/coresight/coresight-etm4x.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
index 20e2e4cb7614..da17b6c49b0f 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x.h
@@ -1036,7 +1036,7 @@ struct etmv4_drvdata {
u8 ctxid_size;
u8 vmid_size;
u8 ccsize;
- u8 ccitmin;
+ u16 ccitmin;
u8 s_ex_level;
u8 ns_ex_level;
u8 q_support;
--
2.34.1