On 18/12/2025 10:17, Krzysztof Kozlowski wrote:
> On 12/12/2025 02:12, Jie Gan wrote:
>>
>>
>> On 12/11/2025 9:37 PM, Rob Herring wrote:
>>> On Thu, Dec 11, 2025 at 02:10:44PM +0800, Jie Gan wrote:
>>>> Add an interrupt property to CTCU device. The interrupt will be triggered
>>>> when the data size in the ETR buffer exceeds the threshold of the
>>>> BYTECNTRVAL register. Programming a threshold in the BYTECNTRVAL register
>>>> of CTCU device will enable the interrupt.
>>>>
>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org>
>>>> Reviewed-by: Mike Leach <mike.leach(a)linaro.org>
>>>> Signed-off-by: Jie Gan <jie.gan(a)oss.qualcomm.com>
>>>> ---
>>>> .../devicetree/bindings/arm/qcom,coresight-ctcu.yaml | 17 +++++++++++++++++
>>>> 1 file changed, 17 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml
>>>> index c969c16c21ef..90f88cc6cd3e 100644
>>>> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml
>>>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml
>>>> @@ -39,6 +39,16 @@ properties:
>>>> items:
>>>> - const: apb
>>>>
>>>> + interrupts:
>>>> + items:
>>>> + - description: Byte cntr interrupt for the first etr device
>>>> + - description: Byte cntr interrupt for the second etr device
This is really vague. How do you define first vs second ? Probe order ?
No way. This must be the "port" number to which the ETR is connected
to the CTCU. IIUC, there is a config area for each ETR (e.g., trace id
filter) connected to the CTCU. I was under the assumption that they
are identified as "ports" (input ports). I don't really understand how
this interrupt mapping works now. Please explain it clearly.
>>>> +
>>>> + interrupt-names:
>>>> + items:
>>>> + - const: etrirq0
>>>> + - const: etrirq1
>>>
>>> Names are kind of pointless when it is just foo<index>.
>>
>> Hi Rob,
>>
>> I was naming them as etr0/etr1. Are these names acceptable?
>
> Obviously irq is redundant, but how does etr0 solves the problem of
> calling it foo0?
>
> I don't think you really read Rob's comment.
>
>> The interrupts are assigned exclusively to a specific ETR device.
>>
>> But Suzuki is concerned that this might cause confusion because the ETR
>> device is named randomly in the driver. Suzuki suggested using ‘port-0’
>> and ‘port-1’ and would also like to hear your feedback on these names.
>
> There is no confusion here. Writing bindings luckily clarifies this what
> the indices in the array mean.
The point is there are "n" interrupts. Question is, could there be more
devices(ETRs) connected to the CTCU than "n".
e.g., Lets CTCU can control upto 4 ETRs and on a particular system, the
TMC-ETR0 -> CTCU-Port0
TMC-ETR1 -> CTCU-Port2
TMC-ETR2 -> CTCU-Port3
Now, how many interrupts are described in the DT ? How do we map which
interrupts correspond to the CTCU-Portn. (Finding the TMC-ETRx back
from the port is possible, with the topology).
This is what I raised in the previous version. Again, happy to hear
if there is a standard way to describe the interrupts.
Suzuki
>
>>
>> Usually, the probe sequence follows the order of the addresses. In our
>> specification, ‘ETR0’ is always probed before ‘ETR1’ because its address
>> is lower.
>
> How is this even relevant? You are answering to something completely
> different, so I don't think you really tried to understand review.
>
>
>
> Best regards,
> Krzysztof
On Tue, 02 Sep 2025 12:21:43 +0800, Jie Gan wrote:
> Update the OSS email addresses across all Coresight documents, as the
> previous addresses have been deprecated.
>
>
Applied, thanks!
[1/1] dt-binding: Update oss email address for Coresight documents
https://git.kernel.org/coresight/c/7009646d937f
Best regards,
--
Suzuki K Poulose <suzuki.poulose(a)arm.com>
Kconfig symbols must not include the CONFIG_ prefix. Remove the CONFIG_
prefix for default values to work.
Fixes: a02509f301c6 ("stm class: Factor out default framing protocol")
Fixes: d69d5e83110f ("stm class: Add MIPI SyS-T protocol support")
Signed-off-by: Leo Yan <leo.yan(a)arm.com>
---
drivers/hwtracing/stm/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwtracing/stm/Kconfig b/drivers/hwtracing/stm/Kconfig
index eda6b11d40a1f9ab49a1ec1e6faae8ee178c5ed3..cd7f0b0f3fbebc74775d8835187e49e5bd21d646 100644
--- a/drivers/hwtracing/stm/Kconfig
+++ b/drivers/hwtracing/stm/Kconfig
@@ -13,7 +13,7 @@ if STM
config STM_PROTO_BASIC
tristate "Basic STM framing protocol driver"
- default CONFIG_STM
+ default STM
help
This is a simple framing protocol for sending data over STM
devices. This was the protocol that the STM framework used
@@ -28,7 +28,7 @@ config STM_PROTO_BASIC
config STM_PROTO_SYS_T
tristate "MIPI SyS-T STM framing protocol driver"
- default CONFIG_STM
+ default STM
help
This is an implementation of MIPI SyS-T protocol to be used
over the STP transport. In addition to the data payload, it
---
base-commit: 40fbbd64bba6c6e7a72885d2f59b6a3be9991eeb
change-id: 20251216-fix_stm_kconfig-a72f40c7612c
Best regards,
--
Leo Yan <leo.yan(a)arm.com>
The current TRBE driver operates only in fill mode, where tracing stops
at the top of buffer and a maintenance interrupt is raised. Due to
interrupt latency, tracing is halted while the program continues to run,
resulting in trace data lose.
This series enhances the driver for the trigger mode to mitigate trace
discontinuity. The circle buffer mode is introduced to avoid any
maintenance interrupts during the snapshot session.
It can be divided into three parts for easier review:
Patches 01~05: Minor refactoring for disabling operations and
clearing status.
Patches 06~12: Refactor fault action and trace size calculation.
Patches 13~19: Support trigger and circle modes. To better utilize the
new buffer modes, perf sets the watermark to
one-quarter of the buffer size.
This series is applied on coresight-next branch and has been validated
on Orion O6 board:
1) The trigger count and wrap mode are verified using Ftrace logs.
2) A new kunit test module verifies limit and count calculations.
3) Basic perf record / script commands and module load/unload have
been tested successfully.
Signed-off-by: Leo Yan <leo.yan(a)arm.com>
---
Leo Yan (19):
coresight: trbe: Use helpers for checking errata
coresight: trbe: Remove redundant disable operation
coresight: trbe: Remove buffer disabling in trbe_handle_overflow()
coresight: trbe: Remove set_trbe_disabled() from the enable flow
coresight: trbe: Refactor status clearing
coresight: trbe: Refactor syndrome decoding
coresight: trbe: Refactor AUX flag setting
coresight: trbe: Use PERF_AUX_FLAG_PARTIAL instead of PERF_AUX_FLAG_COLLISION
coresight: trbe: Add fault action argument to trbe_handle_overflow()
coresight: trbe: Always check fault action when updating buffer
coresight: trbe: Apply overwrite erratum for only wrap event
coresight: trbe: Calculate size for buffer wrapping
coresight: trbe: Remove misleading comment
coresight: trbe: Refactor compute_trbe_buffer_limit()
coresight: trbe: Add static key for bypassing trigger mode
coresight: trbe: Support trigger mode
coresight: trbe: Enable circle mode for snapshot
coresight: trbe: Add kunit tests
perf: cs-etm: Set watermark for AUX trace
drivers/hwtracing/coresight/Kconfig | 9 +
drivers/hwtracing/coresight/Makefile | 1 +
.../coresight/coresight-trbe-kunit-tests.c | 536 +++++++++++++++++++++
drivers/hwtracing/coresight/coresight-trbe.c | 440 +++++++++--------
drivers/hwtracing/coresight/coresight-trbe.h | 111 ++++-
tools/perf/arch/arm/util/cs-etm.c | 7 +
6 files changed, 896 insertions(+), 208 deletions(-)
---
base-commit: 9e9182cab5ebc3ee7544e60ef08ba19fdf216920
change-id: 20251120-trbe_buffer_refactor_v1-1-8f8023105469
Best regards,
--
Leo Yan <leo.yan(a)arm.com>
On 15/12/2025 04:27, Ma Ke wrote:
> In etm_setup_aux(), when a user sink is obtained via
> coresight_get_sink_by_id(), it increments the reference count of the
> sink device. However, if the sink is used in path building, the path
> holds a reference, but the initial reference from
> coresight_get_sink_by_id() is not released, causing a reference count
> leak. We should release the initial reference after the path is built.
>
> Found by code review.
>
> Cc: stable(a)vger.kernel.org
> Fixes: 0e6c20517596 ("coresight: etm-perf: Allow an event to use different sinks")
> Signed-off-by: Ma Ke <make24(a)iscas.ac.cn>
> ---
> Changes in v2:
> - modified the patch as suggestions.
I think Leo's comment on the previous v2 is still unaddressed. But
releasing it in coresight_get_sink_by_id() would make it consistent with
coresight_find_csdev_by_fwnode() and prevent further mistakes.
It also leads me to see that users of coresight_find_device_by_fwnode()
should also release it, but only one out of two appears to.
James
> ---
> drivers/hwtracing/coresight/coresight-etm-perf.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
> index 17afa0f4cdee..56d012ab6d3a 100644
> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> @@ -454,6 +454,11 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
> goto err;
>
> out:
> + if (user_sink) {
> + put_device(&user_sink->dev);
> + user_sink = NULL;
> + }
> +
> return event_data;
>
> err:
The specific config field that an event format attribute is in is
consistently hard coded, even though the API is supposed to be that the
driver publishes the config field name. To stop this pattern from being
copy pasted and causing problems in the future, replace them all with
calls to a new helper that returns the value that a user set.
This reveals some issues in evsel__set_config_if_unset(). It doesn't
work with sparse bitfields, which are an unused but documented feature.
And it also only writes to the attr.config field. To fix it we need to
start tracking user changes for all config fields and then use existing
helper functions that support sparse bitfields. Some other refactoring
was also required and a test was added.
Signed-off-by: James Clark <james.clark(a)linaro.org>
---
Changes in v3:
- Fix uninitialized variable warning on GCC
- Fix leak of evlist in test
- Confirm no type punning issues with ubsan (Ian)
- Link to v2: https://lore.kernel.org/r/20251208-james-perf-config-bits-v2-0-4ac0281993b0…
Changes in v2:
- Remove macros in get_config_chgs() and some other refactoring.
- Support sparse bitfields in evsel__set_config_if_unset().
- Always track user changes instead of only when
'pmu->perf_event_attr_init_default' is set.
- Add a test.
- Don't bail out in cs-etm.c if any format fields are missing (Leo).
- Rename 'guess' to 'synth' (Mike).
- Link to v1: https://lore.kernel.org/r/20251201-james-perf-config-bits-v1-0-22ecbbf8007c…
---
James Clark (12):
perf parse-events: Refactor get_config_terms() to remove macros
perf evsel: Support sparse fields in evsel__set_config_if_unset()
perf parse-events: Track all user changed config bits
perf evsel: apply evsel__set_config_if_unset() to all config fields
perf evsel: Add a helper to get the value of a config field
perf parse-events: Always track user config changes
perf tests: Test evsel__set_config_if_unset() and config change tracking
perf cs-etm: Make a helper to find the Coresight evsel
perf cs-etm: Don't use hard coded config bits when setting up ETMCR
perf cs-etm: Don't use hard coded config bits when setting up TRCCONFIGR
perf cs-etm: Don't hard code config attribute when configuring the event
perf arm-spe: Don't hard code config attribute
tools/perf/arch/arm/util/cs-etm.c | 193 +++++++++++++++------------
tools/perf/arch/arm64/util/arm-spe.c | 15 ++-
tools/perf/tests/pmu.c | 91 +++++++++++++
tools/perf/util/evsel.c | 6 +-
tools/perf/util/evsel.h | 2 +
tools/perf/util/evsel_config.h | 7 +-
tools/perf/util/parse-events.c | 248 ++++++++++++++++++++---------------
tools/perf/util/pmu.c | 112 ++++++++++++++--
8 files changed, 460 insertions(+), 214 deletions(-)
---
base-commit: 2eeb09fe1c5173b659929f92fee4461796ca8c14
change-id: 20251112-james-perf-config-bits-bee7106f0f00
Best regards,
--
James Clark <james.clark(a)linaro.org>