On 23/08/2024 10:57 am, Ganapatrao Kulkarni wrote:
>
> Hi James/Mike,
>
> On 23-08-2024 02:33 pm, James Clark wrote:
>>
>>
>> On 19/08/2024 11:59 am, Mike Leach wrote:
>>> Hi,
>>>
>>> A new branch of OpenCSD is available - ocsd-consistency-checks-1.5.4-rc1
>>>
>>> Testing I managed to do confirms the N atom on unconditional branches
>>> appear to work. I do not have a test case for the range
>>> discontinuities.
>>>
>>> The checks are enabled using operation flags on decoder creation. See
>>> the docs for details.
>>>
>>> Mike
>>>
>>
>> Hi Mike,
>>
>> I tested the new OpenCSD and I don't see the error anymore in the
>> disassembly script. I'm not sure if we need to go any further and add
>> the backwards check, it looks like just a later symptom and the checks
>> that you've added already prevent it.
>>
>> If you release a new version I can send the perf patch. I was going to
>> use these flags if that looks right to you? As far as I know that's the
>> set that can be always on and won't fail on bad hardware?
>>
>> I also assumed that ETM4_OPFLG_PKTDEC_AA64_OPCODE_CHK can be given even
>> for etmv3 and it's just a nop?
>>
>> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>> index e917985bbbe6..90967fd807e6 100644
>> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>> @@ -685,9 +685,14 @@ cs_etm_decoder__create_etm_decoder(struct cs_etm_decoder_params *d_params,
>> return 0;
>>
>> if (d_params->operation == CS_ETM_OPERATION_DECODE) {
>> + int decode_flags = OCSD_CREATE_FLG_FULL_DECODER;
>> +#ifdef OCSD_OPFLG_N_UNCOND_DIR_BR_CHK
>> + decode_flags |= OCSD_OPFLG_N_UNCOND_DIR_BR_CHK | OCSD_OPFLG_CHK_RANGE_CONTINUE |
>> + ETM4_OPFLG_PKTDEC_AA64_OPCODE_CHK;
>> +#endif
>> if (ocsd_dt_create_decoder(decoder->dcd_tree,
>> decoder->decoder_name,
>> - OCSD_CREATE_FLG_FULL_DECODER,
>> + decode_flags,
>> trace_config, &csid))
>> return -1;
>>
>
> I tried Mike's branch with above James's patch and still the segfault is happening to us.
>
Did you update OpenCSD as well?
On 2024/8/23 15:39, Krzysztof Kozlowski wrote:
> On Fri, Aug 23, 2024 at 03:16:07PM +0800, Jinlong Mao wrote:
>>
>>
>> On 2024/8/22 15:41, Krzysztof Kozlowski wrote:
>>> On Wed, Aug 21, 2024 at 11:41:18PM -0700, Mao Jinlong wrote:
>>>> qcom,qmi-id is the instance id used by qmi API to communicate with
>>>> remote processor.
>>>>
>>>> Signed-off-by: Mao Jinlong <quic_jinlmao(a)quicinc.com>
>>>> ---
>>>> .../bindings/arm/qcom,coresight-remote-etm.yaml | 10 ++++++++++
>>>> 1 file changed, 10 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml
>>>> index 4fd5752978cd..27e5f18bfedf 100644
>>>> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml
>>>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml
>>>> @@ -20,6 +20,13 @@ properties:
>>>> compatible:
>>>> const: qcom,coresight-remote-etm
>>>> + qcom,qmi-id:
>>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>>> + description:
>>>> + This id is used by qmi API to communicate with remote processor for
>>>> + enabling and disabling remote etm. Each processor has its unique instance
>>>> + id.
>>>> +
>>>> out-ports:
>>>> $ref: /schemas/graph.yaml#/properties/ports
>>>> additionalProperties: false
>>>> @@ -31,6 +38,7 @@ properties:
>>>> required:
>>>> - compatible
>>>> + - qcom,qmi-id
>>>
>>> That's an ABI break.
>>>
>>> Best regards,
>>> Krzysztof
>> Hi Krzysztof,
>>
>> Sorry, I didn't get your point.
>> Could you please share more details ?
>
> Adding new required properties is an ABI break. Nothing in commit msg
> explained why this is okay or even needed.
>
> Best regards,
> Krzysztof
Thank you. I will update in the commit msg.
>
On 2024/8/22 15:41, Krzysztof Kozlowski wrote:
> On Wed, Aug 21, 2024 at 11:41:18PM -0700, Mao Jinlong wrote:
>> qcom,qmi-id is the instance id used by qmi API to communicate with
>> remote processor.
>>
>> Signed-off-by: Mao Jinlong <quic_jinlmao(a)quicinc.com>
>> ---
>> .../bindings/arm/qcom,coresight-remote-etm.yaml | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml
>> index 4fd5752978cd..27e5f18bfedf 100644
>> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml
>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-remote-etm.yaml
>> @@ -20,6 +20,13 @@ properties:
>> compatible:
>> const: qcom,coresight-remote-etm
>>
>> + qcom,qmi-id:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + description:
>> + This id is used by qmi API to communicate with remote processor for
>> + enabling and disabling remote etm. Each processor has its unique instance
>> + id.
>> +
>> out-ports:
>> $ref: /schemas/graph.yaml#/properties/ports
>> additionalProperties: false
>> @@ -31,6 +38,7 @@ properties:
>>
>> required:
>> - compatible
>> + - qcom,qmi-id
>
> That's an ABI break.
>
> Best regards,
> Krzysztof
Hi Krzysztof,
Sorry, I didn't get your point.
Could you please share more details ?
Thanks
Jinlong Mao
>
>
In our hardware design, by combining a funnel and a replicator, it
implement a hardware device with one-to-one correspondence between
output ports and input ports. The programming usage on this device
is the same as funnel. The software uses a funnel and a static
replicator to implement the driver of this device. Since original
funnels only support a single output connection and original
replicator only support a single input connection, the code needs
to be modified to support this new feature. The following is a
typical topology diagram of multi-port output mechanism.
|----------| |---------| |----------| |---------|
| TPDM 0 | | Source0 | | Source 1 | | TPDM 1 |
|----------| |---------| |----------| |---------|
| | | |
| | | |
| --------- | | |
| | | |
| | | |
| | | |
\-------------/ ---------------------- |
\ Funnel 0 / | |
----------- | ------------------------------
| | |
| | |
\------------------/
\ Funnel 1 / ----|
\--------------/ |
| |----> Combine a funnel and a
| | static replicator
/-----------------\ |
/ replicator 0 \ ----|
/---------------------\
| | |
| | |-----------|
| |---------| |
| |TPDM0 |TPDM1
| \-----------------/
| \ TPDA 0 /
| \-------------/
| |
| |
|Source0/1 |
\-------------------------------/
\ Funnel 2 /
\---------------------------/
Changes in V3:
1. Rename the function "coresight_source_filter" to
"coresight_block_source". And refine this function.
-- Suzuki K Poulose
2. Rename the parameters of the function
"coresight_find_out_connection" to avoid confusion.
-- Suzuki K Poulose
3. Get the source of path in "coresight_enable_path" and
"coresight_disable_path".
-- Suzuki K Poulose
4. Fix filter source device before skip the port in
"coresight_orphan_match".
-- Suzuki K Poulose
5. Make sure the device still orphan if whter is a filter
source firmware node but the filter source device is null.
-- Suzuki K Poulose
6. Walk through the entire coresight bus and fixup the
"filter_src_dev" if the source is being removed.
-- Suzuki K Poulose
7. Refine the commit description of patch#2.
-- Suzuki K Poulose
8. Call "fwnode_handle_put" to "drop" the refcount for the
device firmware node.
-- Suzuki K Poulose
9. Fix the warning reported by kernel test robot.
-- kernel test robot.
10. Use the source device directly if the port has a
hardcoded filter in "tpda_get_element_size".
-- Suzuki K Poulose
Changes in V2:
1. Change the reference for endpoint property in dt-binding.
-- Krzysztof Kozlowski
2. Change the property name "filter_src" to "filter-src".
-- Krzysztof Kozlowski
3. Fix the errors in running 'make dt_binding_check'.
-- Rob Herring
4. Pass in the source parameter instead of path.
-- Suzuki K Poulose
5. Reset the "filter_src_dev" if the "src" csdev is being removed.
-- Suzuki K Poulose
6. Add a warning if the "filter_src_dev" is of not the
type DEV_TYPE_SOURCE.
-- Suzuki K Poulose
7. Optimize the procedure for handling all possible cases.
-- Suzuki K Poulose
Changes in V1:
1. Add a static replicator connect to a funnel to implement the
correspondence between the output ports and the input ports on
funnels.
-- Suzuki K Poulose
2. Add filter_src_dev and filter_src_dev phandle to
"coresight_connection" struct, and populate them if there is one.
-- Suzuki K Poulose
3. To look at the phandle and then fixup/remove the filter_src
device in fixup/remove connections.
-- Suzuki K Poulose
4. When TPDA reads DSB/CMB element size, it is implemented by
looking up filter src device in the connections.
-- Suzuki K Poulose
Tao Zhang (3):
dt-bindings: arm: qcom,coresight-static-replicator: Add property for
source filtering
coresight: Add support for trace filtering by source
coresight-tpda: Optimize the function of reading element size
.../arm/arm,coresight-static-replicator.yaml | 19 ++-
drivers/hwtracing/coresight/coresight-core.c | 136 +++++++++++++++---
.../hwtracing/coresight/coresight-platform.c | 18 +++
drivers/hwtracing/coresight/coresight-tpda.c | 11 +-
include/linux/coresight.h | 5 +
5 files changed, 164 insertions(+), 25 deletions(-)
--
2.17.1
On 22/08/2024 08:08, Krzysztof Kozlowski wrote:
> On Wed, Aug 21, 2024 at 11:38:55AM +0100, Suzuki K Poulose wrote:
>> On 21/08/2024 04:13, Tao Zhang wrote:
>>> The is some "magic" hard coded filtering in the replicators,
>>> which only passes through trace from a particular "source". Add
>>> a new property "filter-src" to label a phandle to the coresight
>>> trace source device matching the hard coded filtering for the port.
>>
>> Minor nit: Please do not use abbreviate "source" in the bindings.
>> I am not an expert on other changes below and will leave it to
>> Rob/Krzysztof to comment.
>>
>> Rob, Krzysztof,
>>
>> We need someway to "link" (add a phandle) from a "port". The patch below
>> is extending "standard" port to add a phandle. Please let us know if
>> there is a better way.
>>
>> e.g.:
>>
>> filters = list of tuples of port, phandle. ?
>>
>> e.g.:
>>
>> filters = < 0, <&tpdm_video>,
>> 1, <&tpdm_mdss>
>> >
>>
>
> Current solution feels like band-aid - what if next time you need some
> second filter? Or "wall"? Or whatever? Next property?
>
> Isn't filter just one endpoint in the graph?
>
> A <--> filter <--> B
To be more precise, "Filter" is a "port (p0, p1, p2 below)" (among a
multi output ports).
For clearer example:
A0 <--> .. <--> ..\ p0 / --> Filtered for (A1) <--> B1
A1 <--> .. <--> .. - < L(filters> p1 - --> Filtered for (A2) <--> B2
A2 <--> .. <--> ../ p2 \ --> Unfiltered <--> B0
> Instead of
>
> A <----through-filter----> B?
The problem is we need to know the components in the path from A0 to X
through, (Not just A0 and L). And also we need to know "which port (p0
vs p1 vs p2)" does the traffic take from a source (A0/A1/A2) out of the
link "L".
So ideally, we need a way to tie p0 -> A1, p1 -> A2.
would we need something else in the future ? I don't know for sure.
People could design their own things ;-). But this was the first time
ever in the last 12yrs since we supported coresight in the kernel.
(there is always a first time).
Fundamentally, the "ports" cannot have additional properties today.
Not sure if there are other usecases (I don't see why). So, we have
to manually extend like above, which I think is not nice.
Happy to proceed with anything that seems acceptable for you folks.
Suzuki
>
> Best regards,
> Krzysztof
>
On 22/08/2024 10:55, Krzysztof Kozlowski wrote:
> On 20/08/2024 08:36, JieGan wrote:
>> On Mon, Aug 19, 2024 at 11:51:41AM +0200, Krzysztof Kozlowski wrote:
>>> On 19/08/2024 10:51, JieGan wrote:
>>>> On Mon, Aug 19, 2024 at 08:25:33AM +0200, Krzysztof Kozlowski wrote:
>>>>> On 19/08/2024 03:49, JieGan wrote:
>>>>>> On Sun, Aug 18, 2024 at 08:28:34AM -0600, Rob Herring wrote:
>>>>>>> On Mon, Aug 12, 2024 at 10:41:39AM +0800, Jie Gan wrote:
>>>>>>>> Add binding file to specify how to define a Coresight TMC
>>>>>>>> Control Unit device in device tree.
>>>>>>>>
>>>>>>>> It is responsible for controlling the data filter function
>>>>>>>> based on the source device's Trace ID for TMC ETR device.
>>>>>>>> The trace data with that Trace id can get into ETR's buffer
>>>>>>>> while other trace data gets ignored.
>>>>>>>>
>>>>>>>> Signed-off-by: Jie Gan <quic_jiegan(a)quicinc.com>
>>>>>>>> ---
>>>>>>>> .../bindings/arm/qcom,coresight-ctcu.yaml | 79 +++++++++++++++++++
>>>>>>>> 1 file changed, 79 insertions(+)
>>>>>>>> create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..7a9580007942
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml
>>>>>>>> @@ -0,0 +1,79 @@
>>>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>>>> +%YAML 1.2
>>>>>>>> +---
>>>>>>>> +$id: http://devicetree.org/schemas/arm/qcom,coresight-ctcu.yaml#
>>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>>>> +
>>>>>>>> +title: CoreSight TMC Control Unit
>>>>>>>> +
>>>>>>>> +maintainers:
>>>>>>>> + - Yuanfang Zhang <quic_yuanfang(a)quicinc.com>
>>>>>>>> + - Mao Jinlong <quic_jinlmao(a)quicinc.com>
>>>>>>>> + - Jie Gan <quic_jiegan(a)quicinc.com>
>>>>>>>> +
>>>>>>>> +description:
>>>>>>>> + The Coresight TMC Control unit controls various Coresight behaviors.
>>>>>>>> + It works as a helper device when connected to TMC ETR device.
>>>>>>>> + It is responsible for controlling the data filter function based on
>>>>>>>> + the source device's Trace ID for TMC ETR device. The trace data with
>>>>>>>> + that Trace id can get into ETR's buffer while other trace data gets
>>>>>>>> + ignored.
>>>>>>>
>>>>>>> Nowhere is TMC defined.
>>>>>> The Coresight TMC control unit(CTCU) connected to Coresight TMC device via replicator and
>>>>>> works as a helper device to TMC device.
>>>>>
>>>>> Did you understand the feedback or just responding with whatever to get
>>>>> rid of reviewers?
>>>>
>>>> Sorry for the insufficient clarity in my response, I am just misunderstood the feedback and try
>>>> to explain the relationship between TMC and CTCU device.
>>>>
>>>> I will add the TMC description to explain what TMC is as shown below:
>>>> The Trace Memory Controller(TMC) is used for Embedded Trace Buffer(ETB), Embedded Trace FIFO(ETF)
>>>> and Embedded Trace Router(ETR) configurations. The configuration mode (ETB, ETF, ETR) is
>>>> discovered at boot time when the device is probed.
>>>
>>> Thanks.
>>>
>>>>
>>>>>
>>>>>>
>>>>>> The in-ports listed below illustrate their connection to TMC devices.
>>>>>>
>>>>>>>
>>>>>>>> +
>>>>>>>> +properties:
>>>>>>>> + compatible:
>>>>>>>> + enum:
>>>>>>>> + - qcom,sa8775p-ctcu
>>>>>>>> +
>>>>>>>> + reg:
>>>>>>>> + maxItems: 1
>>>>>>>> +
>>>>>>>> + clocks:
>>>>>>>> + maxItems: 1
>>>>>>>> +
>>>>>>>> + clock-names:
>>>>>>>> + items:
>>>>>>>> + - const: apb
>>>>>>>> +
>>>>>>>> + in-ports:
>>>>>>>
>>>>>>> Use 'ports' unless you have both in and out ports.
>>>>>> The ‘in-ports’ and ‘out-ports’ properties will be parsed by ‘of_coresight_get_port_parent’
>>>>>> and their relationships to other devices will be stored in the coresight_platform_data structure.
>>>>>>
>>>>>> for example:
>>>>>> struct coresight_platform_data {
>>>>>> int nr_inconns;
>>>>>> int nr_outconns;
>>>>>> struct coresight_connection **out_conns;
>>>>>> struct coresight_connection **in_conns;
>>>>>> };
>>>>>>
>>>>>> https://elixir.bootlin.com/linux/v6.11-rc4/source/drivers/hwtracing/coresig…
>>>>>
>>>>> and? If you respond with some unrelated argument, we will respond with
>>>>> the same: Use 'ports' unless you have both in and out ports.
>>>>
>>>> Sorry for the insufficient response.
>>>>
>>>> The Coresight driver prefers using ‘in-ports’ and ‘out-ports’ instead of the ‘ports’ property, as each
>>>> Coresight component needs to specify its input and output directions.
>>>>
>>>> The Coresight system operates by integrating all Coresight components and construting its data flow path
>>>> based on the defined directions.
>>>>
>>>> Consequently, the data flow direction cannot be determined when utilizing the ‘ports’ property in the
>>>> Coresight system.
>>>
>>> It can be determined. Driver knows that there are only in-ports, so you
>>> cannot have here other direction. Maybe the drivers have somehow this
>>> hard-coded? But that's a bit annoying limitation.
>>>
>> In Coresight platform driver, the of_coresight_get_port_parent function is used to retrieve the parent of the 'ports' node.
>> The function is specifically hard-coded to recognize 'in-ports' and 'out-ports'. I think that's the limitation for
>> 'ports' property.
>>
>> https://elixir.bootlin.com/linux/v6.11-rc4/source/drivers/hwtracing/coresig…
>
> That's a limitation of coresight platform driver, not bindings. Fix your
> drivers.
A bit more of context and history.
We have a generic platform parsing code for parsing the firmware tables
(DT and ACPI) in CoreSight. This will parse most generic bits (read, the
graph connections) to avoid duplicating the code. Most of the components
have both in and out connections (except trace sources and other helper
devices like this TMC CU).
Also, the "previous" (now legacy) DT graph bindings for CoreSight relied
on using standard "ports" with a property to indicate whether a given
port is "input". The platform driver still supports this for any legacy
platform that hasn't moved over (of course with a complaint of using
obsolete bindings in the dmesg).
Now the above proposal is going to conflict with the legacy binding
handling, where "ports" indicate output ports by default, without
the obsolete property and the driver can't differentiate this from
a legacy binding vs modern binding with individual driver to decide
the direction of the port. Nothing unfixable, but I don't understand
what is wrong in calling "input ports" in-ports. But if that is
definitely a no go area, we would need to add "fixup" logic in
individual drivers to "correct" the type of a port (i.e, all output
ports in the parsed data to input ports) and live with it.
Kind regards
Suzuki
>
> Best regards,
> Krzysztof
>
The system on chip (SoC) consists of main APSS(Applications processor
subsytem) and additional processors like modem, lpass. There is
coresight-etm driver for etm trace of APSS. Coresight remote etm driver
is for enabling and disabling the etm trace of remote processors.
It uses QMI interface to communicate with remote processors' software
and uses coresight framework to configure the connection from remote
etm source to TMC sinks.
Example to capture the remote etm trace:
Enable source:
echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink
echo 1 > /sys/bus/coresight/devices/remote_etm0/enable_source
Capture the trace:
cat /dev/tmc_etf0 > /data/remote_etm.bin
Disable source:
echo 0 > /sys/bus/coresight/devices/remote_etm0/enable_source
Change since V2:
1. Change qcom,inst-id to qcom,qmi-id
2. Fix the error in code for type of remote_etm_remove
3. Depend on QMI helper in Kconfig
Changes since V1:
1. Remove unused content
2. Use CORESIGHT_DEV_SUBTYPE_SOURCE_OTHERS as remote etm source type.
3. Use enabled instead of enable in driver data.
4. Validate instance id value where it's read from the DT.
Mao Jinlong (2):
dt-bindings: arm: Add qcom,qmi-id for remote etm
coresight: Add remote etm support
.../arm/qcom,coresight-remote-etm.yaml | 10 +
drivers/hwtracing/coresight/Kconfig | 13 +
drivers/hwtracing/coresight/Makefile | 1 +
drivers/hwtracing/coresight/coresight-qmi.h | 89 +++++
.../coresight/coresight-remote-etm.c | 307 ++++++++++++++++++
5 files changed, 420 insertions(+)
create mode 100644 drivers/hwtracing/coresight/coresight-qmi.h
create mode 100644 drivers/hwtracing/coresight/coresight-remote-etm.c
--
2.41.0
Some HW has static trace id which cannot be changed via
software programming. For this case, configure the trace id
in device tree with "arm,static-trace-id = <xxx>", and
call coresight_trace_id_get_static_system_id with the trace id value
in device probe function. The id will be reserved for the HW
all the time if the device is probed.
Changes since V3:
1. Adda new API function
int coresight_trace_id_get_system_static_id(int trace_id).
2. Use the term "static trace id" for these devices where
the hardware sets a non-programmable trace ID.
Changes since V2:
1. Change "trace-id" to "arm,trace-id".
2. Add trace id flag for getting preferred id or ODD id.
Changes since V1:
1. Add argument to coresight_trace_id_get_system_id for preferred id
instead of adding new function coresight_trace_id_reserve_system_id.
2. Add constraint to trace-id in dt-binding file.
Mao Jinlong (3):
dt-bindings: arm: Add arm,trace-id for coresight dummy source
coresight: Add support to get static id for system trace sources
coresight: dummy: Add static trace id support for dummy source
.../sysfs-bus-coresight-devices-dummy-source | 15 +++++
.../arm/arm,coresight-dummy-source.yaml | 6 ++
drivers/hwtracing/coresight/coresight-dummy.c | 59 +++++++++++++++++--
.../hwtracing/coresight/coresight-platform.c | 26 ++++++++
.../hwtracing/coresight/coresight-trace-id.c | 38 ++++++++----
.../hwtracing/coresight/coresight-trace-id.h | 9 +++
include/linux/coresight.h | 1 +
7 files changed, 140 insertions(+), 14 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-dummy-source
--
2.41.0
On Mon, 12 Aug 2024 12:30:43 +0800, Jie Gan wrote:
> The coresight_disable_source_sysfs function should verify the
> mode of the coresight device before disabling the source.
>
> However, the mode for the TPDM device is always set to
> CS_MODE_DISABLED, resulting in the check consistently failing.
> As a result, TPDM cannot be properly disabled.
>
> [...]
Applied, thanks!
[1/1] Coresight: Set correct cs_mode for TPDM to fix disable issue
https://git.kernel.org/coresight/c/14f5fa9b5fcbe2b3d5098893aba6ad62254d2ef6
Best regards,
--
Suzuki K Poulose <suzuki.poulose(a)arm.com>