Re: [PATCH v3 3/5] dt-bindings: arm: Add Coresight TMC Control Unit hardware

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

That's a limitation of coresight platform driver, not bindings. Fix your
drivers.

Best regards,
Krzysztof





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux