On 19/12/2025 02:05, Jie Gan wrote:
>
>
> On 12/19/2025 7:19 AM, Suzuki K Poulose wrote:
>> 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.
>>
>
> Sorry for the misunderstanding.
>
> Each ETR device should have its own interrupt line and an IRQ register
> within the CTCU device, as defined by the specification. In existing
> projects, the maximum supported number of ETR devices is 2.
>
> Each interrupt is directly mapped to a specific ETR device, for example:
> tmc@1000 → interrupt line 0
> tmc@1001 → interrupt line 1
>
> The suggestion to identify devices by ‘ports’ is much clearer than my
> previous explanation, as it explicitly shows which device is connected
> to which port.
Thanks for confirming.
>
>>>>>> +
>>>>>> + 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).
>>
>
> Got your point and it's much clearer.
>
>> 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.
>>>
>
> My previous explanation was definitely unclear. As Suzuki suggested,
> mapping the interrupt to the port number (to identify the relevant
> device based on topology) makes sense and provides a much easier way to
> understand the relationship between the interrupt and the ETR device.
>
> So with the suggestion, here is the new description about the interrupts:
>
> interrupts:
> items:
> - description: Interrupt for the ETR device connected to in-port0.
> - description: Interrupt for the ETR device connected to in-port1.
>
> interrupt-names:
> items:
> - const: port0
> - const: port1
Which brings us back to the question I posted in the previous version.
Do we really need a "name" or are there other ways to define, a sparse
list of interrupts ?
Suzuki
>
> Thanks,
> Jie
>
>>>
>>>
>>> Best regards,
>>> Krzysztof
>>
>
On 12/18/2025 7:33 PM, Sudeep Holla wrote:
> On Thu, Dec 18, 2025 at 12:09:40AM -0800, Yuanfang Zhang wrote:
>> This patch series adds support for CoreSight components local to CPU clusters,
>> including funnel, replicator, and TMC, which reside within CPU cluster power
>> domains. These components require special handling due to power domain
>> constraints.
>>
>
> Could you clarify why PSCI-based power domains associated with clusters in
> domain-idle-states cannot address these requirements, given that PSCI CPU-idle
> OSI mode was originally intended to support them? My understanding of this
> patch series is that OSI mode is unable to do so, which, if accurate, appears
> to be a flaw that should be corrected.
It is due to the particular characteristics of the CPU cluster power domain.Runtime PM for CPU devices works little different, it is mostly used to manage hierarchical
CPU topology (PSCI OSI mode) to talk with genpd framework to manage the last CPU handling in
cluster.
It doesn’t really send IPI to wakeup CPU device (It don’t have .power_on/.power_off) callback
implemented which gets invoked from .runtime_resume callback. This behavior is aligned with
the upstream Kernel.
>
>> Unlike system-level CoreSight devices, these components share the CPU cluster's
>> power domain. When the cluster enters low-power mode (LPM), their registers
>> become inaccessible. Notably, `pm_runtime_get` alone cannot bring the cluster
>> out of LPM, making standard register access unreliable.
>>
>
> Are these devices the only ones on the system that are uniquely bound to
> cluster-level power domains? If not, what additional devices share this
> dependency so that we can understand how they are managed in comparison?
>
Yes, devices like ETM and TRBE also share this power domain and access constraint.
Their drivers naturally handle enablement/disablement on the specific CPU they
belong to (e.g., via hotplug callbacks or existing smp_call_function paths).
>> To address this, the series introduces:
>> - Identifying cluster-bound devices via a new `qcom,cpu-bound-components`
>> device tree property.
>
> Really, no please.
>
Our objective is to determine which CoreSight components are physically locate
within the CPU cluster power domain.
Would it be acceptable to derive this relationship from the existing power-domains binding?
For example, if a Funnel or Replicator node is linked to a power-domains entry that specifies a cpumask,
the driver could recognize this shared dependency and automatically apply the appropriate cluster-aware behavior.
thanks,
yuanfang.
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>