diff mbox series

[v1,1/7] dt-bindings: arm: Add support for Coresight TGU trace

Message ID 20240830092311.14400-2-quic_songchai@quicinc.com (mailing list archive)
State New, archived
Headers show
Series Provides support for Trigger Generation Unit | expand

Commit Message

Songwei Chai Aug. 30, 2024, 9:23 a.m. UTC
The Trigger Generation Unit (TGU) is designed to detect patterns or
sequences within a specific region of the System on Chip (SoC). Once
configured and activated, it monitors sense inputs and can detect a
pre-programmed state or sequence across clock cycles, subsequently
producing a trigger.

   TGU configuration space
        offset table
 x-------------------------x
 |                         |
 |                         |
 |                         |                           Step configuration
 |                         |                             space layout
 |   coresight management  |                           x-------------x
 |        registers        |                     |---> |             |
 |                         |                     |     |  reserve    |
 |                         |                     |     |             |
 |-------------------------|                     |     |-------------|
 |                         |                     |     | prioroty[3] |
 |         step[7]         |<--                  |     |-------------|
 |-------------------------|   |                 |     | prioroty[2] |
 |                         |   |                 |     |-------------|
 |           ...           |   |Steps region     |     | prioroty[1] |
 |                         |   |                 |     |-------------|
 |-------------------------|   |                 |     | prioroty[0] |
 |                         |<--                  |     |-------------|
 |         step[0]         |-------------------->      |             |
 |-------------------------|                           |  condition  |
 |                         |                           |             |
 |     control and status  |                           x-------------x
 |           space         |                           |             |
 x-------------------------x                           |Timer/Counter|
                                                       |             |
						       x-------------x
TGU Configuration in Hardware

The TGU provides a step region for user configuration, similar
to a flow chart. Each step region consists of three register clusters:

1.Priority Region: Sets the required signals with priority.
2.Condition Region: Defines specific requirements (e.g., signal A
reaches three times) and the subsequent action once the requirement is
met.
3.Timer/Counter (Optional): Provides timing or counting functionality.

Add a new coresight-tgu.yaml file to describe the bindings required to
define the TGU in the device trees.

Signed-off-by: songchai <quic_songchai@quicinc.com>
---
 .../bindings/arm/qcom,coresight-tgu.yaml      | 136 ++++++++++++++++++
 1 file changed, 136 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml

Comments

Krzysztof Kozlowski Aug. 30, 2024, 10:11 a.m. UTC | #1
On 30/08/2024 11:23, songchai wrote:
> The Trigger Generation Unit (TGU) is designed to detect patterns or
> sequences within a specific region of the System on Chip (SoC). Once
> configured and activated, it monitors sense inputs and can detect a
> pre-programmed state or sequence across clock cycles, subsequently
> producing a trigger.
> 
>    TGU configuration space
>         offset table
>  x-------------------------x
>  |                         |
>  |                         |
>  |                         |                           Step configuration
>  |                         |                             space layout
>  |   coresight management  |                           x-------------x
>  |        registers        |                     |---> |             |
>  |                         |                     |     |  reserve    |
>  |                         |                     |     |             |
>  |-------------------------|                     |     |-------------|
>  |                         |                     |     | prioroty[3] |
>  |         step[7]         |<--                  |     |-------------|
>  |-------------------------|   |                 |     | prioroty[2] |
>  |                         |   |                 |     |-------------|
>  |           ...           |   |Steps region     |     | prioroty[1] |
>  |                         |   |                 |     |-------------|
>  |-------------------------|   |                 |     | prioroty[0] |
>  |                         |<--                  |     |-------------|
>  |         step[0]         |-------------------->      |             |
>  |-------------------------|                           |  condition  |
>  |                         |                           |             |
>  |     control and status  |                           x-------------x
>  |           space         |                           |             |
>  x-------------------------x                           |Timer/Counter|
>                                                        |             |
> 						       x-------------x
> TGU Configuration in Hardware
> 
> The TGU provides a step region for user configuration, similar
> to a flow chart. Each step region consists of three register clusters:
> 
> 1.Priority Region: Sets the required signals with priority.
> 2.Condition Region: Defines specific requirements (e.g., signal A
> reaches three times) and the subsequent action once the requirement is
> met.
> 3.Timer/Counter (Optional): Provides timing or counting functionality.
> 
> Add a new coresight-tgu.yaml file to describe the bindings required to
> define the TGU in the device trees.
> 
> Signed-off-by: songchai <quic_songchai@quicinc.com>

It feels like you are using login name as real name. Please investigate
this and confirm whether latin transcription/transliteration of your
name is like above.

> ---
>  .../bindings/arm/qcom,coresight-tgu.yaml      | 136 ++++++++++++++++++
>  1 file changed, 136 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml
> new file mode 100644
> index 000000000000..c261252e33e0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml
> @@ -0,0 +1,136 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +# Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/qcom,coresight-tgu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Trigger Generation Unit - TGU
> +
> +description: |
> +  The Trigger Generation Unit (TGU) is a Data Engine which can be utilized
> +  to sense a plurality of signals and create a trigger into the CTI or
> +  generate interrupts to processors. The TGU is like the trigger circuit
> +  of a Logic Analyzer.The corresponding trigger logic can be realized by
> +  configuring the conditions for each step after sensing the signal.
> +  Once setup and enabled, it will observe sense inputs and based upon
> +  the activity of those inputs, even over clock cycles, may detect a
> +  preprogrammed state/sequence and then produce a trigger or interrupt.
> +
> +  The primary use case of the TGU is to detect patterns or sequences on a
> +  given set of signals within some region of the SoC.
> +
> +maintainers:
> +  - Mao Jinlong <quic_jinlmao@quicinc.com>
> +  - Sam Chai <quic_songchai@quicinc.com>
> +
> +# Need a custom select here or 'arm,primecell' will match on lots of nodes
> +select:
> +  properties:
> +    compatible:
> +      contains:
> +        enum:
> +          - qcom,coresight-tgu
> +  required:
> +    - compatible
> +
> +properties:
> +  $nodename:
> +    pattern: "^tgu(@[0-9a-f]+)$"

Drop the pattern (and anyway @ is not optional).

> +  compatible:
> +    items:
> +      - const: qcom,coresight-tgu
> +      - const: arm,primecell
> +
> +  reg:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
> +
> +  clock-names:
> +    items:
> +      - const: apb_pclk
> +
> +  qcom,tgu-steps:
> +    description:
> +      The trigger logic is realized by configuring each step after sensing
> +      the signal. The parameter here is used to describe the maximum of steps
> +      that could be configured in the current TGU.

Why this is board or SoC level property? All below also feel like
unnecessary stuff from downstream.

> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    minimum: 1
> +    maximum: 8
> +
> +  qcom,tgu-regs:
> +    description:
> +      There are some "groups" register clusters in each step, which are used to configure the signal
> +      that we want to detect.Meanwhile, each group has its own priority, and the priority increases
> +      with number of groups.For example, group3 has a higher priority than group2 ,the signal configured
> +      in group3 will be sensed more preferentially than the signal which is configured in group2.
> +      The parameter here is used to describe the signal number that each group could be configured.
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    minimum: 1
> +    maximum: 18
> +
> +  qcom,tgu-conditions:
> +    description:
> +      A condition sets a specific requirement for a step and defines the subsequent
> +      action once the requirement is met. For example, in step two, if signal A is
> +      detected three times, the process jumps back to step one. The parameter describes
> +      the register number for each functionality, whether it is setting a specific
> +      requirement or defining a subsequent action.
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    minimum: 1
> +    maximum: 4
> +
> +  qcom,tgu-timer-counters:
> +    description:
> +      TGU has timer and counter which are used to set some requirement on each step.
> +      For example, we could use counter to create a trigger into CTI once TGU senses
> +      the target signal three times.This parameter is used to describe the number of
> +      Timers/Counters in TGU.
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    minimum: 0
> +    maximum: 2
> +
> +  in-ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +    additionalProperties: false
> +
> +    properties:
> +      port:
> +        description: AXI Slave connected to another Coresight component
> +        $ref: /schemas/graph.yaml#/properties/port
> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - clock-names
> +
> +additionalProperties: false
> +
> +examples:
> +  # minimum TGU definition.

Drop comment

> +  - |
> +    tgu@10b0e000 {
> +        compatible = "qcom,coresight-tgu", "arm,primecell";
> +        reg = <0x10b0e000 0x1000>;
> +
Best regards,
Krzysztof
Trilok Soni Aug. 30, 2024, 4:44 p.m. UTC | #2
On 8/30/2024 3:11 AM, Krzysztof Kozlowski wrote:
>> Add a new coresight-tgu.yaml file to describe the bindings required to
>> define the TGU in the device trees.
>>
>> Signed-off-by: songchai <quic_songchai@quicinc.com>
> It feels like you are using login name as real name. Please investigate
> this and confirm whether latin transcription/transliteration of your
> name is like above.

It should be "Signed-off-by: Sam Chai <quic_songchai@quicinc.com>" ?
Trilok Soni Aug. 30, 2024, 10:15 p.m. UTC | #3
On 8/30/2024 2:23 AM, songchai wrote:
>  |                         |                     |     |             |
>  |-------------------------|                     |     |-------------|
>  |                         |                     |     | prioroty[3] |


s/prioroty/priority
Krzysztof Kozlowski Sept. 2, 2024, 7:02 a.m. UTC | #4
On 02/09/2024 05:14, songchai wrote:
> 
> On 8/30/2024 6:11 PM, Krzysztof Kozlowski wrote:
>> On 30/08/2024 11:23, songchai wrote:
>>> The Trigger Generation Unit (TGU) is designed to detect patterns or
>>> sequences within a specific region of the System on Chip (SoC). Once
>>> configured and activated, it monitors sense inputs and can detect a
>>> pre-programmed state or sequence across clock cycles, subsequently
>>> producing a trigger.
>>>
>>>     TGU configuration space
>>>          offset table
>>>   x-------------------------x
>>>   |                         |
>>>   |                         |
>>>   |                         |                           Step configuration
>>>   |                         |                             space layout
>>>   |   coresight management  |                           x-------------x
>>>   |        registers        |                     |---> |             |
>>>   |                         |                     |     |  reserve    |
>>>   |                         |                     |     |             |
>>>   |-------------------------|                     |     |-------------|
>>>   |                         |                     |     | prioroty[3] |
>>>   |         step[7]         |<--                  |     |-------------|
>>>   |-------------------------|   |                 |     | prioroty[2] |
>>>   |                         |   |                 |     |-------------|
>>>   |           ...           |   |Steps region     |     | prioroty[1] |
>>>   |                         |   |                 |     |-------------|
>>>   |-------------------------|   |                 |     | prioroty[0] |
>>>   |                         |<--                  |     |-------------|
>>>   |         step[0]         |-------------------->      |             |
>>>   |-------------------------|                           |  condition  |
>>>   |                         |                           |             |
>>>   |     control and status  |                           x-------------x
>>>   |           space         |                           |             |
>>>   x-------------------------x                           |Timer/Counter|
>>>                                                         |             |
>>> 						       x-------------x
>>> TGU Configuration in Hardware
>>>
>>> The TGU provides a step region for user configuration, similar
>>> to a flow chart. Each step region consists of three register clusters:
>>>
>>> 1.Priority Region: Sets the required signals with priority.
>>> 2.Condition Region: Defines specific requirements (e.g., signal A
>>> reaches three times) and the subsequent action once the requirement is
>>> met.
>>> 3.Timer/Counter (Optional): Provides timing or counting functionality.
>>>
>>> Add a new coresight-tgu.yaml file to describe the bindings required to
>>> define the TGU in the device trees.
>>>
>>> Signed-off-by: songchai<quic_songchai@quicinc.com>
>> It feels like you are using login name as real name. Please investigate
>> this and confirm whether latin transcription/transliteration of your
>> name is like above.
> yes.. it's my login name. Will use my real name in next version.
>>
>>> ---
>>>   .../bindings/arm/qcom,coresight-tgu.yaml      | 136 ++++++++++++++++++
>>>   1 file changed, 136 insertions(+)
>>>   create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml
>>> new file mode 100644
>>> index 000000000000..c261252e33e0
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml
>>> @@ -0,0 +1,136 @@
>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>>> +# Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
>>> +%YAML 1.2
>>> +---
>>> +$id:http://devicetree.org/schemas/arm/qcom,coresight-tgu.yaml#
>>> +$schema:http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Trigger Generation Unit - TGU
>>> +
>>> +description: |
>>> +  The Trigger Generation Unit (TGU) is a Data Engine which can be utilized
>>> +  to sense a plurality of signals and create a trigger into the CTI or
>>> +  generate interrupts to processors. The TGU is like the trigger circuit
>>> +  of a Logic Analyzer.The corresponding trigger logic can be realized by
>>> +  configuring the conditions for each step after sensing the signal.
>>> +  Once setup and enabled, it will observe sense inputs and based upon
>>> +  the activity of those inputs, even over clock cycles, may detect a
>>> +  preprogrammed state/sequence and then produce a trigger or interrupt.
>>> +
>>> +  The primary use case of the TGU is to detect patterns or sequences on a
>>> +  given set of signals within some region of the SoC.
>>> +
>>> +maintainers:
>>> +  - Mao Jinlong<quic_jinlmao@quicinc.com>
>>> +  - Sam Chai<quic_songchai@quicinc.com>
>>> +
>>> +# Need a custom select here or 'arm,primecell' will match on lots of nodes
>>> +select:
>>> +  properties:
>>> +    compatible:
>>> +      contains:
>>> +        enum:
>>> +          - qcom,coresight-tgu
>>> +  required:
>>> +    - compatible
>>> +
>>> +properties:
>>> +  $nodename:
>>> +    pattern: "^tgu(@[0-9a-f]+)$"
>> Drop the pattern (and anyway @ is not optional).
> 
> There will be several TGUs in the SoC, and we want to use the address of 
> each to distinguish them.

How is this related?

> 
> This is why we added the nodename pattern here.

How is this related?

> 
> Additionally, I noticed that both TPDM and CTI also use this format to 
> define the nodename.
> 
> Could you please share any concerns you have about using this pattern?

I don't get why you insist, but sure:
The name does not follow DT spec recommendation, plus child schema is
not really supposed to define the names.

> 
>>
>>> +  compatible:
>>> +    items:
>>> +      - const: qcom,coresight-tgu
>>> +      - const: arm,primecell
>>> +
>>> +  reg:
>>> +    maxItems: 1
>>> +
>>> +  clocks:
>>> +    maxItems: 1
>>> +
>>> +  clock-names:
>>> +    items:
>>> +      - const: apb_pclk
>>> +
>>> +  qcom,tgu-steps:
>>> +    description:
>>> +      The trigger logic is realized by configuring each step after sensing
>>> +      the signal. The parameter here is used to describe the maximum of steps
>>> +      that could be configured in the current TGU.
>> Why this is board or SoC level property? All below also feel like
>> unnecessary stuff from downstream.
> 
> There are actually four properties used to describe the number of 
> registers with different functionality for TGUs at the SoC level.
> 
> Each TGU may have a different number of registers, so we need to add 
> these four properties to describe each TGU’s hardware design.

Each TGU on the same SoC?



Best regards,
Krzysztof
Songwei Chai Sept. 2, 2024, 7:24 a.m. UTC | #5
On 9/2/2024 3:02 PM, Krzysztof Kozlowski wrote:
> On 02/09/2024 05:14, songchai wrote:
>> On 8/30/2024 6:11 PM, Krzysztof Kozlowski wrote:
>>> On 30/08/2024 11:23, songchai wrote:
>>>> The Trigger Generation Unit (TGU) is designed to detect patterns or
>>>> sequences within a specific region of the System on Chip (SoC). Once
>>>> configured and activated, it monitors sense inputs and can detect a
>>>> pre-programmed state or sequence across clock cycles, subsequently
>>>> producing a trigger.
>>>>
>>>>      TGU configuration space
>>>>           offset table
>>>>    x-------------------------x
>>>>    |                         |
>>>>    |                         |
>>>>    |                         |                           Step configuration
>>>>    |                         |                             space layout
>>>>    |   coresight management  |                           x-------------x
>>>>    |        registers        |                     |---> |             |
>>>>    |                         |                     |     |  reserve    |
>>>>    |                         |                     |     |             |
>>>>    |-------------------------|                     |     |-------------|
>>>>    |                         |                     |     | prioroty[3] |
>>>>    |         step[7]         |<--                  |     |-------------|
>>>>    |-------------------------|   |                 |     | prioroty[2] |
>>>>    |                         |   |                 |     |-------------|
>>>>    |           ...           |   |Steps region     |     | prioroty[1] |
>>>>    |                         |   |                 |     |-------------|
>>>>    |-------------------------|   |                 |     | prioroty[0] |
>>>>    |                         |<--                  |     |-------------|
>>>>    |         step[0]         |-------------------->      |             |
>>>>    |-------------------------|                           |  condition  |
>>>>    |                         |                           |             |
>>>>    |     control and status  |                           x-------------x
>>>>    |           space         |                           |             |
>>>>    x-------------------------x                           |Timer/Counter|
>>>>                                                          |             |
>>>> 						       x-------------x
>>>> TGU Configuration in Hardware
>>>>
>>>> The TGU provides a step region for user configuration, similar
>>>> to a flow chart. Each step region consists of three register clusters:
>>>>
>>>> 1.Priority Region: Sets the required signals with priority.
>>>> 2.Condition Region: Defines specific requirements (e.g., signal A
>>>> reaches three times) and the subsequent action once the requirement is
>>>> met.
>>>> 3.Timer/Counter (Optional): Provides timing or counting functionality.
>>>>
>>>> Add a new coresight-tgu.yaml file to describe the bindings required to
>>>> define the TGU in the device trees.
>>>>
>>>> Signed-off-by: songchai<quic_songchai@quicinc.com>
>>> It feels like you are using login name as real name. Please investigate
>>> this and confirm whether latin transcription/transliteration of your
>>> name is like above.
>> yes.. it's my login name. Will use my real name in next version.
>>>> ---
>>>>    .../bindings/arm/qcom,coresight-tgu.yaml      | 136 ++++++++++++++++++
>>>>    1 file changed, 136 insertions(+)
>>>>    create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml
>>>> new file mode 100644
>>>> index 000000000000..c261252e33e0
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml
>>>> @@ -0,0 +1,136 @@
>>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>>>> +# Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
>>>> +%YAML 1.2
>>>> +---
>>>> +$id:http://devicetree.org/schemas/arm/qcom,coresight-tgu.yaml#
>>>> +$schema:http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Trigger Generation Unit - TGU
>>>> +
>>>> +description: |
>>>> +  The Trigger Generation Unit (TGU) is a Data Engine which can be utilized
>>>> +  to sense a plurality of signals and create a trigger into the CTI or
>>>> +  generate interrupts to processors. The TGU is like the trigger circuit
>>>> +  of a Logic Analyzer.The corresponding trigger logic can be realized by
>>>> +  configuring the conditions for each step after sensing the signal.
>>>> +  Once setup and enabled, it will observe sense inputs and based upon
>>>> +  the activity of those inputs, even over clock cycles, may detect a
>>>> +  preprogrammed state/sequence and then produce a trigger or interrupt.
>>>> +
>>>> +  The primary use case of the TGU is to detect patterns or sequences on a
>>>> +  given set of signals within some region of the SoC.
>>>> +
>>>> +maintainers:
>>>> +  - Mao Jinlong<quic_jinlmao@quicinc.com>
>>>> +  - Sam Chai<quic_songchai@quicinc.com>
>>>> +
>>>> +# Need a custom select here or 'arm,primecell' will match on lots of nodes
>>>> +select:
>>>> +  properties:
>>>> +    compatible:
>>>> +      contains:
>>>> +        enum:
>>>> +          - qcom,coresight-tgu
>>>> +  required:
>>>> +    - compatible
>>>> +
>>>> +properties:
>>>> +  $nodename:
>>>> +    pattern: "^tgu(@[0-9a-f]+)$"
>>> Drop the pattern (and anyway @ is not optional).
>> There will be several TGUs in the SoC, and we want to use the address of
>> each to distinguish them.
> How is this related?
>
>> This is why we added the nodename pattern here.
> How is this related?
>
>> Additionally, I noticed that both TPDM and CTI also use this format to
>> define the nodename.
>>
>> Could you please share any concerns you have about using this pattern?
> I don't get why you insist, but sure:
> The name does not follow DT spec recommendation, plus child schema is
> not really supposed to define the names.
Thanks for you clarification, will drop in the next version.
>
>>>> +  compatible:
>>>> +    items:
>>>> +      - const: qcom,coresight-tgu
>>>> +      - const: arm,primecell
>>>> +
>>>> +  reg:
>>>> +    maxItems: 1
>>>> +
>>>> +  clocks:
>>>> +    maxItems: 1
>>>> +
>>>> +  clock-names:
>>>> +    items:
>>>> +      - const: apb_pclk
>>>> +
>>>> +  qcom,tgu-steps:
>>>> +    description:
>>>> +      The trigger logic is realized by configuring each step after sensing
>>>> +      the signal. The parameter here is used to describe the maximum of steps
>>>> +      that could be configured in the current TGU.
>>> Why this is board or SoC level property? All below also feel like
>>> unnecessary stuff from downstream.
>> There are actually four properties used to describe the number of
>> registers with different functionality for TGUs at the SoC level.
>>
>> Each TGU may have a different number of registers, so we need to add
>> these four properties to describe each TGU’s hardware design.
> Each TGU on the same SoC?
yes, in other words, there will be several TGUs in the SoC.
>
>
>
> Best regards,
> Krzysztof
>
Krzysztof Kozlowski Sept. 2, 2024, 8:05 a.m. UTC | #6
On 02/09/2024 09:24, songchai wrote:
> 
> On 9/2/2024 3:02 PM, Krzysztof Kozlowski wrote:
>> On 02/09/2024 05:14, songchai wrote:
>>> On 8/30/2024 6:11 PM, Krzysztof Kozlowski wrote:
>>>> On 30/08/2024 11:23, songchai wrote:
>>>>> The Trigger Generation Unit (TGU) is designed to detect patterns or
>>>>> sequences within a specific region of the System on Chip (SoC). Once
>>>>> configured and activated, it monitors sense inputs and can detect a
>>>>> pre-programmed state or sequence across clock cycles, subsequently
>>>>> producing a trigger.
>>>>>
>>>>>      TGU configuration space
>>>>>           offset table
>>>>>    x-------------------------x
>>>>>    |                         |
>>>>>    |                         |
>>>>>    |                         |                           Step configuration
>>>>>    |                         |                             space layout
>>>>>    |   coresight management  |                           x-------------x
>>>>>    |        registers        |                     |---> |             |
>>>>>    |                         |                     |     |  reserve    |
>>>>>    |                         |                     |     |             |
>>>>>    |-------------------------|                     |     |-------------|
>>>>>    |                         |                     |     | prioroty[3] |
>>>>>    |         step[7]         |<--                  |     |-------------|
>>>>>    |-------------------------|   |                 |     | prioroty[2] |
>>>>>    |                         |   |                 |     |-------------|
>>>>>    |           ...           |   |Steps region     |     | prioroty[1] |
>>>>>    |                         |   |                 |     |-------------|
>>>>>    |-------------------------|   |                 |     | prioroty[0] |
>>>>>    |                         |<--                  |     |-------------|
>>>>>    |         step[0]         |-------------------->      |             |
>>>>>    |-------------------------|                           |  condition  |
>>>>>    |                         |                           |             |
>>>>>    |     control and status  |                           x-------------x
>>>>>    |           space         |                           |             |
>>>>>    x-------------------------x                           |Timer/Counter|
>>>>>                                                          |             |
>>>>> 						       x-------------x
>>>>> TGU Configuration in Hardware
>>>>>
>>>>> The TGU provides a step region for user configuration, similar
>>>>> to a flow chart. Each step region consists of three register clusters:
>>>>>
>>>>> 1.Priority Region: Sets the required signals with priority.
>>>>> 2.Condition Region: Defines specific requirements (e.g., signal A
>>>>> reaches three times) and the subsequent action once the requirement is
>>>>> met.
>>>>> 3.Timer/Counter (Optional): Provides timing or counting functionality.
>>>>>
>>>>> Add a new coresight-tgu.yaml file to describe the bindings required to
>>>>> define the TGU in the device trees.
>>>>>
>>>>> Signed-off-by: songchai<quic_songchai@quicinc.com>
>>>> It feels like you are using login name as real name. Please investigate
>>>> this and confirm whether latin transcription/transliteration of your
>>>> name is like above.
>>> yes.. it's my login name. Will use my real name in next version.
>>>>> ---
>>>>>    .../bindings/arm/qcom,coresight-tgu.yaml      | 136 ++++++++++++++++++
>>>>>    1 file changed, 136 insertions(+)
>>>>>    create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml
>>>>> new file mode 100644
>>>>> index 000000000000..c261252e33e0
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml
>>>>> @@ -0,0 +1,136 @@
>>>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>>>>> +# Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
>>>>> +%YAML 1.2
>>>>> +---
>>>>> +$id:http://devicetree.org/schemas/arm/qcom,coresight-tgu.yaml#
>>>>> +$schema:http://devicetree.org/meta-schemas/core.yaml#
>>>>> +
>>>>> +title: Trigger Generation Unit - TGU
>>>>> +
>>>>> +description: |
>>>>> +  The Trigger Generation Unit (TGU) is a Data Engine which can be utilized
>>>>> +  to sense a plurality of signals and create a trigger into the CTI or
>>>>> +  generate interrupts to processors. The TGU is like the trigger circuit
>>>>> +  of a Logic Analyzer.The corresponding trigger logic can be realized by
>>>>> +  configuring the conditions for each step after sensing the signal.
>>>>> +  Once setup and enabled, it will observe sense inputs and based upon
>>>>> +  the activity of those inputs, even over clock cycles, may detect a
>>>>> +  preprogrammed state/sequence and then produce a trigger or interrupt.
>>>>> +
>>>>> +  The primary use case of the TGU is to detect patterns or sequences on a
>>>>> +  given set of signals within some region of the SoC.
>>>>> +
>>>>> +maintainers:
>>>>> +  - Mao Jinlong<quic_jinlmao@quicinc.com>
>>>>> +  - Sam Chai<quic_songchai@quicinc.com>
>>>>> +
>>>>> +# Need a custom select here or 'arm,primecell' will match on lots of nodes
>>>>> +select:
>>>>> +  properties:
>>>>> +    compatible:
>>>>> +      contains:
>>>>> +        enum:
>>>>> +          - qcom,coresight-tgu
>>>>> +  required:
>>>>> +    - compatible
>>>>> +
>>>>> +properties:
>>>>> +  $nodename:
>>>>> +    pattern: "^tgu(@[0-9a-f]+)$"
>>>> Drop the pattern (and anyway @ is not optional).
>>> There will be several TGUs in the SoC, and we want to use the address of
>>> each to distinguish them.
>> How is this related?
>>
>>> This is why we added the nodename pattern here.
>> How is this related?
>>
>>> Additionally, I noticed that both TPDM and CTI also use this format to
>>> define the nodename.
>>>
>>> Could you please share any concerns you have about using this pattern?
>> I don't get why you insist, but sure:
>> The name does not follow DT spec recommendation, plus child schema is
>> not really supposed to define the names.
> Thanks for you clarification, will drop in the next version.
>>
>>>>> +  compatible:
>>>>> +    items:
>>>>> +      - const: qcom,coresight-tgu
>>>>> +      - const: arm,primecell
>>>>> +
>>>>> +  reg:
>>>>> +    maxItems: 1
>>>>> +
>>>>> +  clocks:
>>>>> +    maxItems: 1
>>>>> +
>>>>> +  clock-names:
>>>>> +    items:
>>>>> +      - const: apb_pclk
>>>>> +
>>>>> +  qcom,tgu-steps:
>>>>> +    description:
>>>>> +      The trigger logic is realized by configuring each step after sensing
>>>>> +      the signal. The parameter here is used to describe the maximum of steps
>>>>> +      that could be configured in the current TGU.
>>>> Why this is board or SoC level property? All below also feel like
>>>> unnecessary stuff from downstream.
>>> There are actually four properties used to describe the number of
>>> registers with different functionality for TGUs at the SoC level.
>>>
>>> Each TGU may have a different number of registers, so we need to add
>>> these four properties to describe each TGU’s hardware design.
>> Each TGU on the same SoC?
> yes, in other words, there will be several TGUs in the SoC.

This I understood, but I am asking if each TGU on the same SoC will have
different number of registers and other properties?

Best regards,
Krzysztof
Krzysztof Kozlowski Sept. 2, 2024, 10:24 a.m. UTC | #7
On 02/09/2024 12:10, songchai wrote:
> 
> On 9/2/2024 4:05 PM, Krzysztof Kozlowski wrote:
>> On 02/09/2024 09:24, songchai wrote:
>>> On 9/2/2024 3:02 PM, Krzysztof Kozlowski wrote:
>>>> On 02/09/2024 05:14, songchai wrote:
>>>>> On 8/30/2024 6:11 PM, Krzysztof Kozlowski wrote:
>>>>>> On 30/08/2024 11:23, songchai wrote:
>>>>>>> The Trigger Generation Unit (TGU) is designed to detect patterns or
>>>>>>> sequences within a specific region of the System on Chip (SoC). Once
>>>>>>> configured and activated, it monitors sense inputs and can detect a
>>>>>>> pre-programmed state or sequence across clock cycles, subsequently
>>>>>>> producing a trigger.
>>>>>>>
>>>>>>>       TGU configuration space
>>>>>>>            offset table
>>>>>>>     x-------------------------x
>>>>>>>     |                         |
>>>>>>>     |                         |
>>>>>>>     |                         |                           Step configuration
>>>>>>>     |                         |                             space layout
>>>>>>>     |   coresight management  |                           x-------------x
>>>>>>>     |        registers        |                     |---> |             |
>>>>>>>     |                         |                     |     |  reserve    |
>>>>>>>     |                         |                     |     |             |
>>>>>>>     |-------------------------|                     |     |-------------|
>>>>>>>     |                         |                     |     | prioroty[3] |
>>>>>>>     |         step[7]         |<--                  |     |-------------|
>>>>>>>     |-------------------------|   |                 |     | prioroty[2] |
>>>>>>>     |                         |   |                 |     |-------------|
>>>>>>>     |           ...           |   |Steps region     |     | prioroty[1] |
>>>>>>>     |                         |   |                 |     |-------------|
>>>>>>>     |-------------------------|   |                 |     | prioroty[0] |
>>>>>>>     |                         |<--                  |     |-------------|
>>>>>>>     |         step[0]         |-------------------->      |             |
>>>>>>>     |-------------------------|                           |  condition  |
>>>>>>>     |                         |                           |             |
>>>>>>>     |     control and status  |                           x-------------x
>>>>>>>     |           space         |                           |             |
>>>>>>>     x-------------------------x                           |Timer/Counter|
>>>>>>>                                                           |             |
>>>>>>> 						       x-------------x
>>>>>>> TGU Configuration in Hardware
>>>>>>>
>>>>>>> The TGU provides a step region for user configuration, similar
>>>>>>> to a flow chart. Each step region consists of three register clusters:
>>>>>>>
>>>>>>> 1.Priority Region: Sets the required signals with priority.
>>>>>>> 2.Condition Region: Defines specific requirements (e.g., signal A
>>>>>>> reaches three times) and the subsequent action once the requirement is
>>>>>>> met.
>>>>>>> 3.Timer/Counter (Optional): Provides timing or counting functionality.
>>>>>>>
>>>>>>> Add a new coresight-tgu.yaml file to describe the bindings required to
>>>>>>> define the TGU in the device trees.
>>>>>>>
>>>>>>> Signed-off-by: songchai<quic_songchai@quicinc.com>
>>>>>> It feels like you are using login name as real name. Please investigate
>>>>>> this and confirm whether latin transcription/transliteration of your
>>>>>> name is like above.
>>>>> yes.. it's my login name. Will use my real name in next version.
>>>>>>> ---
>>>>>>>     .../bindings/arm/qcom,coresight-tgu.yaml      | 136 ++++++++++++++++++
>>>>>>>     1 file changed, 136 insertions(+)
>>>>>>>     create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml
>>>>>>> new file mode 100644
>>>>>>> index 000000000000..c261252e33e0
>>>>>>> --- /dev/null
>>>>>>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml
>>>>>>> @@ -0,0 +1,136 @@
>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>>>>>>> +# Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
>>>>>>> +%YAML 1.2
>>>>>>> +---
>>>>>>> +$id:http://devicetree.org/schemas/arm/qcom,coresight-tgu.yaml#
>>>>>>> +$schema:http://devicetree.org/meta-schemas/core.yaml#
>>>>>>> +
>>>>>>> +title: Trigger Generation Unit - TGU
>>>>>>> +
>>>>>>> +description: |
>>>>>>> +  The Trigger Generation Unit (TGU) is a Data Engine which can be utilized
>>>>>>> +  to sense a plurality of signals and create a trigger into the CTI or
>>>>>>> +  generate interrupts to processors. The TGU is like the trigger circuit
>>>>>>> +  of a Logic Analyzer.The corresponding trigger logic can be realized by
>>>>>>> +  configuring the conditions for each step after sensing the signal.
>>>>>>> +  Once setup and enabled, it will observe sense inputs and based upon
>>>>>>> +  the activity of those inputs, even over clock cycles, may detect a
>>>>>>> +  preprogrammed state/sequence and then produce a trigger or interrupt.
>>>>>>> +
>>>>>>> +  The primary use case of the TGU is to detect patterns or sequences on a
>>>>>>> +  given set of signals within some region of the SoC.
>>>>>>> +
>>>>>>> +maintainers:
>>>>>>> +  - Mao Jinlong<quic_jinlmao@quicinc.com>
>>>>>>> +  - Sam Chai<quic_songchai@quicinc.com>
>>>>>>> +
>>>>>>> +# Need a custom select here or 'arm,primecell' will match on lots of nodes
>>>>>>> +select:
>>>>>>> +  properties:
>>>>>>> +    compatible:
>>>>>>> +      contains:
>>>>>>> +        enum:
>>>>>>> +          - qcom,coresight-tgu
>>>>>>> +  required:
>>>>>>> +    - compatible
>>>>>>> +
>>>>>>> +properties:
>>>>>>> +  $nodename:
>>>>>>> +    pattern: "^tgu(@[0-9a-f]+)$"
>>>>>> Drop the pattern (and anyway @ is not optional).
>>>>> There will be several TGUs in the SoC, and we want to use the address of
>>>>> each to distinguish them.
>>>> How is this related?
>>>>
>>>>> This is why we added the nodename pattern here.
>>>> How is this related?
>>>>
>>>>> Additionally, I noticed that both TPDM and CTI also use this format to
>>>>> define the nodename.
>>>>>
>>>>> Could you please share any concerns you have about using this pattern?
>>>> I don't get why you insist, but sure:
>>>> The name does not follow DT spec recommendation, plus child schema is
>>>> not really supposed to define the names.
>>> Thanks for you clarification, will drop in the next version.
>>>>>>> +  compatible:
>>>>>>> +    items:
>>>>>>> +      - const: qcom,coresight-tgu
>>>>>>> +      - const: arm,primecell
>>>>>>> +
>>>>>>> +  reg:
>>>>>>> +    maxItems: 1
>>>>>>> +
>>>>>>> +  clocks:
>>>>>>> +    maxItems: 1
>>>>>>> +
>>>>>>> +  clock-names:
>>>>>>> +    items:
>>>>>>> +      - const: apb_pclk
>>>>>>> +
>>>>>>> +  qcom,tgu-steps:
>>>>>>> +    description:
>>>>>>> +      The trigger logic is realized by configuring each step after sensing
>>>>>>> +      the signal. The parameter here is used to describe the maximum of steps
>>>>>>> +      that could be configured in the current TGU.
>>>>>> Why this is board or SoC level property? All below also feel like
>>>>>> unnecessary stuff from downstream.
>>>>> There are actually four properties used to describe the number of
>>>>> registers with different functionality for TGUs at the SoC level.
>>>>>
>>>>> Each TGU may have a different number of registers, so we need to add
>>>>> these four properties to describe each TGU’s hardware design.
>>>> Each TGU on the same SoC?
>>> yes, in other words, there will be several TGUs in the SoC.
>> This I understood, but I am asking if each TGU on the same SoC will have
>> different number of registers and other properties?
> 
> yes, each TGU has a different number of registers.
> 
> For example, some TGUs support 6 steps, while others support only 4 steps.
> 
> These variations depend on the hardware design, so we need properties to 
> describe.

You keep avoiding the answer. ON THE SAME SOC.

Point to your upstream DTS using this.

Best regards,
Krzysztof
Krzysztof Kozlowski Sept. 3, 2024, 11:30 a.m. UTC | #8
On 03/09/2024 05:16, songchai wrote:
> 
> On 9/2/2024 6:24 PM, Krzysztof Kozlowski wrote:
>> On 02/09/2024 12:10, songchai wrote:
>>> On 9/2/2024 4:05 PM, Krzysztof Kozlowski wrote:
>>>> On 02/09/2024 09:24, songchai wrote:
>>>>> On 9/2/2024 3:02 PM, Krzysztof Kozlowski wrote:
>>>>>> On 02/09/2024 05:14, songchai wrote:
>>>>>>> On 8/30/2024 6:11 PM, Krzysztof Kozlowski wrote:
>>>>>>>> On 30/08/2024 11:23, songchai wrote:
>>>>>>>>> The Trigger Generation Unit (TGU) is designed to detect patterns or
>>>>>>>>> sequences within a specific region of the System on Chip (SoC). Once
>>>>>>>>> configured and activated, it monitors sense inputs and can detect a
>>>>>>>>> pre-programmed state or sequence across clock cycles, subsequently
>>>>>>>>> producing a trigger.
>>>>>>>>>
>>>>>>>>>        TGU configuration space
>>>>>>>>>             offset table
>>>>>>>>>      x-------------------------x
>>>>>>>>>      |                         |
>>>>>>>>>      |                         |
>>>>>>>>>      |                         |                           Step configuration
>>>>>>>>>      |                         |                             space layout
>>>>>>>>>      |   coresight management  |                           x-------------x
>>>>>>>>>      |        registers        |                     |---> |             |
>>>>>>>>>      |                         |                     |     |  reserve    |
>>>>>>>>>      |                         |                     |     |             |
>>>>>>>>>      |-------------------------|                     |     |-------------|
>>>>>>>>>      |                         |                     |     | prioroty[3] |
>>>>>>>>>      |         step[7]         |<--                  |     |-------------|
>>>>>>>>>      |-------------------------|   |                 |     | prioroty[2] |
>>>>>>>>>      |                         |   |                 |     |-------------|
>>>>>>>>>      |           ...           |   |Steps region     |     | prioroty[1] |
>>>>>>>>>      |                         |   |                 |     |-------------|
>>>>>>>>>      |-------------------------|   |                 |     | prioroty[0] |
>>>>>>>>>      |                         |<--                  |     |-------------|
>>>>>>>>>      |         step[0]         |-------------------->      |             |
>>>>>>>>>      |-------------------------|                           |  condition  |
>>>>>>>>>      |                         |                           |             |
>>>>>>>>>      |     control and status  |                           x-------------x
>>>>>>>>>      |           space         |                           |             |
>>>>>>>>>      x-------------------------x                           |Timer/Counter|
>>>>>>>>>                                                            |             |
>>>>>>>>> 						       x-------------x
>>>>>>>>> TGU Configuration in Hardware
>>>>>>>>>
>>>>>>>>> The TGU provides a step region for user configuration, similar
>>>>>>>>> to a flow chart. Each step region consists of three register clusters:
>>>>>>>>>
>>>>>>>>> 1.Priority Region: Sets the required signals with priority.
>>>>>>>>> 2.Condition Region: Defines specific requirements (e.g., signal A
>>>>>>>>> reaches three times) and the subsequent action once the requirement is
>>>>>>>>> met.
>>>>>>>>> 3.Timer/Counter (Optional): Provides timing or counting functionality.
>>>>>>>>>
>>>>>>>>> Add a new coresight-tgu.yaml file to describe the bindings required to
>>>>>>>>> define the TGU in the device trees.
>>>>>>>>>
>>>>>>>>> Signed-off-by: songchai<quic_songchai@quicinc.com>
>>>>>>>> It feels like you are using login name as real name. Please investigate
>>>>>>>> this and confirm whether latin transcription/transliteration of your
>>>>>>>> name is like above.
>>>>>>> yes.. it's my login name. Will use my real name in next version.
>>>>>>>>> ---
>>>>>>>>>      .../bindings/arm/qcom,coresight-tgu.yaml      | 136 ++++++++++++++++++
>>>>>>>>>      1 file changed, 136 insertions(+)
>>>>>>>>>      create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml
>>>>>>>>>
>>>>>>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml
>>>>>>>>> new file mode 100644
>>>>>>>>> index 000000000000..c261252e33e0
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml
>>>>>>>>> @@ -0,0 +1,136 @@
>>>>>>>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>>>>>>>>> +# Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
>>>>>>>>> +%YAML 1.2
>>>>>>>>> +---
>>>>>>>>> +$id:http://devicetree.org/schemas/arm/qcom,coresight-tgu.yaml#
>>>>>>>>> +$schema:http://devicetree.org/meta-schemas/core.yaml#
>>>>>>>>> +
>>>>>>>>> +title: Trigger Generation Unit - TGU
>>>>>>>>> +
>>>>>>>>> +description: |
>>>>>>>>> +  The Trigger Generation Unit (TGU) is a Data Engine which can be utilized
>>>>>>>>> +  to sense a plurality of signals and create a trigger into the CTI or
>>>>>>>>> +  generate interrupts to processors. The TGU is like the trigger circuit
>>>>>>>>> +  of a Logic Analyzer.The corresponding trigger logic can be realized by
>>>>>>>>> +  configuring the conditions for each step after sensing the signal.
>>>>>>>>> +  Once setup and enabled, it will observe sense inputs and based upon
>>>>>>>>> +  the activity of those inputs, even over clock cycles, may detect a
>>>>>>>>> +  preprogrammed state/sequence and then produce a trigger or interrupt.
>>>>>>>>> +
>>>>>>>>> +  The primary use case of the TGU is to detect patterns or sequences on a
>>>>>>>>> +  given set of signals within some region of the SoC.
>>>>>>>>> +
>>>>>>>>> +maintainers:
>>>>>>>>> +  - Mao Jinlong<quic_jinlmao@quicinc.com>
>>>>>>>>> +  - Sam Chai<quic_songchai@quicinc.com>
>>>>>>>>> +
>>>>>>>>> +# Need a custom select here or 'arm,primecell' will match on lots of nodes
>>>>>>>>> +select:
>>>>>>>>> +  properties:
>>>>>>>>> +    compatible:
>>>>>>>>> +      contains:
>>>>>>>>> +        enum:
>>>>>>>>> +          - qcom,coresight-tgu
>>>>>>>>> +  required:
>>>>>>>>> +    - compatible
>>>>>>>>> +
>>>>>>>>> +properties:
>>>>>>>>> +  $nodename:
>>>>>>>>> +    pattern: "^tgu(@[0-9a-f]+)$"
>>>>>>>> Drop the pattern (and anyway @ is not optional).
>>>>>>> There will be several TGUs in the SoC, and we want to use the address of
>>>>>>> each to distinguish them.
>>>>>> How is this related?
>>>>>>
>>>>>>> This is why we added the nodename pattern here.
>>>>>> How is this related?
>>>>>>
>>>>>>> Additionally, I noticed that both TPDM and CTI also use this format to
>>>>>>> define the nodename.
>>>>>>>
>>>>>>> Could you please share any concerns you have about using this pattern?
>>>>>> I don't get why you insist, but sure:
>>>>>> The name does not follow DT spec recommendation, plus child schema is
>>>>>> not really supposed to define the names.
>>>>> Thanks for you clarification, will drop in the next version.
>>>>>>>>> +  compatible:
>>>>>>>>> +    items:
>>>>>>>>> +      - const: qcom,coresight-tgu
>>>>>>>>> +      - const: arm,primecell
>>>>>>>>> +
>>>>>>>>> +  reg:
>>>>>>>>> +    maxItems: 1
>>>>>>>>> +
>>>>>>>>> +  clocks:
>>>>>>>>> +    maxItems: 1
>>>>>>>>> +
>>>>>>>>> +  clock-names:
>>>>>>>>> +    items:
>>>>>>>>> +      - const: apb_pclk
>>>>>>>>> +
>>>>>>>>> +  qcom,tgu-steps:
>>>>>>>>> +    description:
>>>>>>>>> +      The trigger logic is realized by configuring each step after sensing
>>>>>>>>> +      the signal. The parameter here is used to describe the maximum of steps
>>>>>>>>> +      that could be configured in the current TGU.
>>>>>>>> Why this is board or SoC level property? All below also feel like
>>>>>>>> unnecessary stuff from downstream.
>>>>>>> There are actually four properties used to describe the number of
>>>>>>> registers with different functionality for TGUs at the SoC level.
>>>>>>>
>>>>>>> Each TGU may have a different number of registers, so we need to add
>>>>>>> these four properties to describe each TGU’s hardware design.
>>>>>> Each TGU on the same SoC?
>>>>> yes, in other words, there will be several TGUs in the SoC.
>>>> This I understood, but I am asking if each TGU on the same SoC will have
>>>> different number of registers and other properties?
>>> yes, each TGU has a different number of registers.
>>>
>>> For example, some TGUs support 6 steps, while others support only 4 steps.
>>>
>>> These variations depend on the hardware design, so we need properties to
>>> describe.
>> You keep avoiding the answer. ON THE SAME SOC.
>>
>> Point to your upstream DTS using this.
> 
> I reviewed the hardware design of our chipset and found the following:
> 
>   * In the SM8450, there are three TGUs on the same SoC. However, only
>     one TGU has timer and counter registers to support time/counter
>     functionality.
>   * Additionally, in the SM8450, the “tgu-regs” configuration varies:
>     some TGUs have 8 registers, while others have only 5 registers.
> 
> To answer question - yes, on the same soc, will have different number of 
> registers and other properties.

Thank you, this is valid reason for the property.

Best regards,
Krzysztof
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml
new file mode 100644
index 000000000000..c261252e33e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tgu.yaml
@@ -0,0 +1,136 @@ 
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+# Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/qcom,coresight-tgu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Trigger Generation Unit - TGU
+
+description: |
+  The Trigger Generation Unit (TGU) is a Data Engine which can be utilized
+  to sense a plurality of signals and create a trigger into the CTI or
+  generate interrupts to processors. The TGU is like the trigger circuit
+  of a Logic Analyzer.The corresponding trigger logic can be realized by
+  configuring the conditions for each step after sensing the signal.
+  Once setup and enabled, it will observe sense inputs and based upon
+  the activity of those inputs, even over clock cycles, may detect a
+  preprogrammed state/sequence and then produce a trigger or interrupt.
+
+  The primary use case of the TGU is to detect patterns or sequences on a
+  given set of signals within some region of the SoC.
+
+maintainers:
+  - Mao Jinlong <quic_jinlmao@quicinc.com>
+  - Sam Chai <quic_songchai@quicinc.com>
+
+# Need a custom select here or 'arm,primecell' will match on lots of nodes
+select:
+  properties:
+    compatible:
+      contains:
+        enum:
+          - qcom,coresight-tgu
+  required:
+    - compatible
+
+properties:
+  $nodename:
+    pattern: "^tgu(@[0-9a-f]+)$"
+  compatible:
+    items:
+      - const: qcom,coresight-tgu
+      - const: arm,primecell
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  clock-names:
+    items:
+      - const: apb_pclk
+
+  qcom,tgu-steps:
+    description:
+      The trigger logic is realized by configuring each step after sensing
+      the signal. The parameter here is used to describe the maximum of steps
+      that could be configured in the current TGU.
+    $ref: /schemas/types.yaml#/definitions/uint32
+    minimum: 1
+    maximum: 8
+
+  qcom,tgu-regs:
+    description:
+      There are some "groups" register clusters in each step, which are used to configure the signal
+      that we want to detect.Meanwhile, each group has its own priority, and the priority increases
+      with number of groups.For example, group3 has a higher priority than group2 ,the signal configured
+      in group3 will be sensed more preferentially than the signal which is configured in group2.
+      The parameter here is used to describe the signal number that each group could be configured.
+    $ref: /schemas/types.yaml#/definitions/uint32
+    minimum: 1
+    maximum: 18
+
+  qcom,tgu-conditions:
+    description:
+      A condition sets a specific requirement for a step and defines the subsequent
+      action once the requirement is met. For example, in step two, if signal A is
+      detected three times, the process jumps back to step one. The parameter describes
+      the register number for each functionality, whether it is setting a specific
+      requirement or defining a subsequent action.
+    $ref: /schemas/types.yaml#/definitions/uint32
+    minimum: 1
+    maximum: 4
+
+  qcom,tgu-timer-counters:
+    description:
+      TGU has timer and counter which are used to set some requirement on each step.
+      For example, we could use counter to create a trigger into CTI once TGU senses
+      the target signal three times.This parameter is used to describe the number of
+      Timers/Counters in TGU.
+    $ref: /schemas/types.yaml#/definitions/uint32
+    minimum: 0
+    maximum: 2
+
+  in-ports:
+    $ref: /schemas/graph.yaml#/properties/ports
+    additionalProperties: false
+
+    properties:
+      port:
+        description: AXI Slave connected to another Coresight component
+        $ref: /schemas/graph.yaml#/properties/port
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+
+additionalProperties: false
+
+examples:
+  # minimum TGU definition.
+  - |
+    tgu@10b0e000 {
+        compatible = "qcom,coresight-tgu", "arm,primecell";
+        reg = <0x10b0e000 0x1000>;
+
+        clocks = <&aoss_qmp>;
+        clock-names = "apb_pclk";
+
+        qcom,tgu-steps = <3>;
+        qcom,tgu-regs = <4>;
+        qcom,tgu-conditions = <4>;
+        qcom,tgu-timer-counters = <1>;
+
+        in-ports {
+            port {
+                tgu_in_tpdm_swao: endpoint{
+                    remote-endpoint = <&tpdm_swao_out_tgu>;
+                };
+            };
+        };
+    };
+...