Message-ID: <d117e157-f2e2-4e17-bbe4-b84001eae1bb@kernel.org>
Date: Mon, 19 Aug 2024 11:51:41 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: JieGan <quic_jiegan@...cinc.com>
Cc: Rob Herring <robh@...nel.org>, Suzuki K Poulose <suzuki.poulose@....com>,
 Mike Leach <mike.leach@...aro.org>, James Clark <james.clark@...aro.org>,
 Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
 Maxime Coquelin <mcoquelin.stm32@...il.com>,
 Alexandre Torgue <alexandre.torgue@...s.st.com>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konrad.dybcio@...aro.org>,
 Jinlong Mao <quic_jinlmao@...cinc.com>, coresight@...ts.linaro.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org, Tingwei Zhang <quic_tingweiz@...cinc.com>,
 Yuanfang Zhang <quic_yuanfang@...cinc.com>,
 Tao Zhang <quic_taozha@...cinc.com>, Song Chai <quic_songchai@...cinc.com>,
 linux-arm-msm@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com
Subject: Re: [PATCH v3 3/5] dt-bindings: arm: Add Coresight TMC Control Unit
 hardware

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@...cinc.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@...cinc.com>
>>>>> +  - Mao Jinlong <quic_jinlmao@...cinc.com>
>>>>> +  - Jie Gan <quic_jiegan@...cinc.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/coresight/coresight-platform.c#L147
>>
>> 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.

Best regards,
Krzysztof

Powered by blists - more mailing lists