diff mbox series

[1/4] dt-bindings: arm: qcom,coresight-funnel: Add label for multi-ouput

Message ID 1711009927-17873-2-git-send-email-quic_taozha@quicinc.com (mailing list archive)
State New, archived
Headers show
Series Add support for multi-port output on the funnel | expand

Commit Message

Tao Zhang March 21, 2024, 8:32 a.m. UTC
Add new property "label" to label the source corresponding to the
output connection. When the funnel supports multi-output, this
property needs to be introduced to mark which source component a
certain output connection corresponds to.

Signed-off-by: Tao Zhang <quic_taozha@quicinc.com>
---
 .../arm/arm,coresight-dynamic-funnel.yaml     | 34 ++++++++++++++++---
 1 file changed, 30 insertions(+), 4 deletions(-)

Comments

Rob Herring (Arm) March 21, 2024, 2:42 p.m. UTC | #1
On Thu, Mar 21, 2024 at 04:32:04PM +0800, Tao Zhang wrote:
> Add new property "label" to label the source corresponding to the
> output connection. When the funnel supports multi-output, this
> property needs to be introduced to mark which source component a
> certain output connection corresponds to.
> 
> Signed-off-by: Tao Zhang <quic_taozha@quicinc.com>
> ---
>  .../arm/arm,coresight-dynamic-funnel.yaml     | 34 ++++++++++++++++---
>  1 file changed, 30 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
> index 44a1041cb0fc..cde62c286d29 100644
> --- a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
> +++ b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
> @@ -66,13 +66,39 @@ properties:
>          $ref: /schemas/graph.yaml#/properties/port
>  
>    out-ports:
> -    $ref: /schemas/graph.yaml#/properties/ports
> -    additionalProperties: false
> -
> +    type: object
>      properties:
> +      "#address-cells":
> +        const: 1
> +
> +      "#size-cells":
> +        const: 0
> +
>        port:
> +        type: object
> +
> +    patternProperties:
> +      '^port(@[0-7])?$':
> +        type: object
>          description: Output connection to CoreSight Trace bus
> -        $ref: /schemas/graph.yaml#/properties/port

Nope, now you have no constraints on port node properties. Please look 
at how other bindings are done to add properties on endpoint node.

> +
> +        patternProperties:
> +          "^endpoint(@[0-9a-f]+)?$":
> +            type: object
> +            properties:
> +              remote-endpoint:
> +                description: |
> +                  phandle to an 'endpoint' subnode of a remote device node.
> +                  $ref: /schemas/types.yaml#/definitions/phandle

Don't need this.

> +              label:
> +                description: Label the source corresponding to the output connection
> +                $ref: /schemas/types.yaml#/definitions/string

label already has a type.

As this node is an output, aren't you labeling what the destination is, 
not the "source"?

Why can't you look at the remote connection to identify what it is?


> +    oneOf:
> +      - required:
> +          - port
> +      - required:
> +          - "#address-cells"
> +          - "#size-cells"

The common schema that you removed handles this.

Rob
Suzuki K Poulose March 21, 2024, 2:52 p.m. UTC | #2
On 21/03/2024 14:42, Rob Herring wrote:
> On Thu, Mar 21, 2024 at 04:32:04PM +0800, Tao Zhang wrote:
>> Add new property "label" to label the source corresponding to the
>> output connection. When the funnel supports multi-output, this
>> property needs to be introduced to mark which source component a
>> certain output connection corresponds to.
>>
>> Signed-off-by: Tao Zhang <quic_taozha@quicinc.com>
>> ---
>>   .../arm/arm,coresight-dynamic-funnel.yaml     | 34 ++++++++++++++++---
>>   1 file changed, 30 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>> index 44a1041cb0fc..cde62c286d29 100644
>> --- a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>> +++ b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>> @@ -66,13 +66,39 @@ properties:
>>           $ref: /schemas/graph.yaml#/properties/port
>>   
>>     out-ports:
>> -    $ref: /schemas/graph.yaml#/properties/ports
>> -    additionalProperties: false
>> -
>> +    type: object
>>       properties:
>> +      "#address-cells":
>> +        const: 1
>> +
>> +      "#size-cells":
>> +        const: 0
>> +
>>         port:
>> +        type: object
>> +
>> +    patternProperties:
>> +      '^port(@[0-7])?$':
>> +        type: object
>>           description: Output connection to CoreSight Trace bus
>> -        $ref: /schemas/graph.yaml#/properties/port
> 
> Nope, now you have no constraints on port node properties. Please look
> at how other bindings are done to add properties on endpoint node.
> 
>> +
>> +        patternProperties:
>> +          "^endpoint(@[0-9a-f]+)?$":
>> +            type: object
>> +            properties:
>> +              remote-endpoint:
>> +                description: |
>> +                  phandle to an 'endpoint' subnode of a remote device node.
>> +                  $ref: /schemas/types.yaml#/definitions/phandle
> 
> Don't need this.
> 
>> +              label:
>> +                description: Label the source corresponding to the output connection
>> +                $ref: /schemas/types.yaml#/definitions/string
> 
> label already has a type.
> 
> As this node is an output, aren't you labeling what the destination is,
> not the "source"?
> 
> Why can't you look at the remote connection to identify what it is?

+1


Suzuki


> 
> 
>> +    oneOf:
>> +      - required:
>> +          - port
>> +      - required:
>> +          - "#address-cells"
>> +          - "#size-cells"
> 
> The common schema that you removed handles this.
> 
> Rob
Tingwei Zhang March 22, 2024, 7:02 a.m. UTC | #3
On 3/21/2024 10:42 PM, Rob Herring wrote:
> On Thu, Mar 21, 2024 at 04:32:04PM +0800, Tao Zhang wrote:
>> Add new property "label" to label the source corresponding to the
>> output connection. When the funnel supports multi-output, this
>> property needs to be introduced to mark which source component a
>> certain output connection corresponds to.
>>
>> Signed-off-by: Tao Zhang <quic_taozha@quicinc.com>
>> ---
>>   .../arm/arm,coresight-dynamic-funnel.yaml     | 34 ++++++++++++++++---
>>   1 file changed, 30 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>> index 44a1041cb0fc..cde62c286d29 100644
>> --- a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>> +++ b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>> @@ -66,13 +66,39 @@ properties:
>>           $ref: /schemas/graph.yaml#/properties/port
>>   
>>     out-ports:
>> -    $ref: /schemas/graph.yaml#/properties/ports
>> -    additionalProperties: false
>> -
>> +    type: object
>>       properties:
>> +      "#address-cells":
>> +        const: 1
>> +
>> +      "#size-cells":
>> +        const: 0
>> +
>>         port:
>> +        type: object
>> +
>> +    patternProperties:
>> +      '^port(@[0-7])?$':
>> +        type: object
>>           description: Output connection to CoreSight Trace bus
>> -        $ref: /schemas/graph.yaml#/properties/port
> 
> Nope, now you have no constraints on port node properties. Please look
> at how other bindings are done to add properties on endpoint node.
> 
Thanks for pointing this out, Rob. Shall we ref port-base and
endpoint-base then add new properties on endpoint? In this way, the 
redundant code from port schema is not required.
>> +
>> +        patternProperties:
>> +          "^endpoint(@[0-9a-f]+)?$":
>> +            type: object
>> +            properties:
>> +              remote-endpoint:
>> +                description: |
>> +                  phandle to an 'endpoint' subnode of a remote device node.
>> +                  $ref: /schemas/types.yaml#/definitions/phandle
> 
> Don't need this.
> 
>> +              label:
>> +                description: Label the source corresponding to the output connection
>> +                $ref: /schemas/types.yaml#/definitions/string
> 
> label already has a type.
> 
> As this node is an output, aren't you labeling what the destination is,
> not the "source"?
> 
> Why can't you look at the remote connection to identify what it is?
>
This funnel can route data stream from different trace source to 
different output ports. This lable property is added to describe which 
source is routed to this output port.

For example, the graph is as below. Funnel3 routes trace data from TPDM0 
to output[0] and output[0] of funnel3 is connected to input[0] of TPDA0.
While Funnels routes trace data from TPDM1 to output[1] which connects 
to input[1] of TPDA0. Hope that clarifies this a little bit.

|---------|    |---------|    |---------|    |---------|    |---------|
|  TPDM0  |    |  TPDM1  |    |  TPDM2  |    |  TPDM3  |    |  TPDM4  |
|---------|    |---------|    |---------|    |---------|    |---------|
     |               |             |               |              |
     |               |             |               |              |
     |               |             |               |              |
     |-----|   |-----|             |-----|   |-----|              |
           |   |                         |   |                    |
           |   |                         |   |                    |
        [0]|   |[1]                   [0]|   |[1]                 |
      \-------------/               \-------------/        \------------/
       \  FUNNEL0  /                 \  FUNNEL1  /          \  FUNNEL2  /
        -----------                   -----------            -----------
             |                             |                      |
      \-------------/               \-------------/               |
       \  FUNNEL3  /                 \  FUNNEL4  /                |
        -----------                   -----------                 |
           |  |                         |   |
        [0]|  |[1]                   [0]|   |[1]                  |
           |  |----------               |   |                     |
           |            |               |   |                     |
           |-------|    |      |------- |   |          |--------- |
                   |    |      |            |          |
                   |    |      |            |          |
                [0]|    |[1]   |[2]         |[3]       |[4]
            \ ---------------------------------------------------/
             \                     TPDA0                        /
              \                                                /
               ------------------------------------------------

> 
>> +    oneOf:
>> +      - required:
>> +          - port
>> +      - required:
>> +          - "#address-cells"
>> +          - "#size-cells"
> 
> The common schema that you removed handles this.
> 
> Rob
Suzuki K Poulose March 22, 2024, 9:42 a.m. UTC | #4
On 22/03/2024 07:02, Tingwei Zhang wrote:
> On 3/21/2024 10:42 PM, Rob Herring wrote:
>> On Thu, Mar 21, 2024 at 04:32:04PM +0800, Tao Zhang wrote:
>>> Add new property "label" to label the source corresponding to the
>>> output connection. When the funnel supports multi-output, this
>>> property needs to be introduced to mark which source component a
>>> certain output connection corresponds to.
>>>
>>> Signed-off-by: Tao Zhang <quic_taozha@quicinc.com>
>>> ---
>>>   .../arm/arm,coresight-dynamic-funnel.yaml     | 34 ++++++++++++++++---
>>>   1 file changed, 30 insertions(+), 4 deletions(-)
>>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>>> index 44a1041cb0fc..cde62c286d29 100644
>>> --- 
>>> a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>>> +++ 
>>> b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>>> @@ -66,13 +66,39 @@ properties:
>>>           $ref: /schemas/graph.yaml#/properties/port
>>>     out-ports:
>>> -    $ref: /schemas/graph.yaml#/properties/ports
>>> -    additionalProperties: false
>>> -
>>> +    type: object
>>>       properties:
>>> +      "#address-cells":
>>> +        const: 1
>>> +
>>> +      "#size-cells":
>>> +        const: 0
>>> +
>>>         port:
>>> +        type: object
>>> +
>>> +    patternProperties:
>>> +      '^port(@[0-7])?$':
>>> +        type: object
>>>           description: Output connection to CoreSight Trace bus
>>> -        $ref: /schemas/graph.yaml#/properties/port
>>
>> Nope, now you have no constraints on port node properties. Please look
>> at how other bindings are done to add properties on endpoint node.
>>
> Thanks for pointing this out, Rob. Shall we ref port-base and
> endpoint-base then add new properties on endpoint? In this way, the 
> redundant code from port schema is not required.
>>> +
>>> +        patternProperties:
>>> +          "^endpoint(@[0-9a-f]+)?$":
>>> +            type: object
>>> +            properties:
>>> +              remote-endpoint:
>>> +                description: |
>>> +                  phandle to an 'endpoint' subnode of a remote 
>>> device node.
>>> +                  $ref: /schemas/types.yaml#/definitions/phandle
>>
>> Don't need this.
>>
>>> +              label:
>>> +                description: Label the source corresponding to the 
>>> output connection
>>> +                $ref: /schemas/types.yaml#/definitions/string
>>
>> label already has a type.
>>
>> As this node is an output, aren't you labeling what the destination is,
>> not the "source"?
>>
>> Why can't you look at the remote connection to identify what it is?
>>
> This funnel can route data stream from different trace source to 
> different output ports. This lable property is added to describe which 
> source is routed to this output port.
> 
> For example, the graph is as below. Funnel3 routes trace data from TPDM0 
> to output[0] and output[0] of funnel3 is connected to input[0] of TPDA0.

Funnel3 and Funnel4 are really Replicators ! How are they Funnels ? 
Again, my question still stands. Are Funnel(Replicator-renamed)3/4 and 
Funnel 0/1/2 programmable ?

Suzuki


> While Funnels routes trace data from TPDM1 to output[1] which connects 
> to input[1] of TPDA0. Hope that clarifies this a little bit.
> 
> |---------|    |---------|    |---------|    |---------|    |---------|
> |  TPDM0  |    |  TPDM1  |    |  TPDM2  |    |  TPDM3  |    |  TPDM4  |
> |---------|    |---------|    |---------|    |---------|    |---------|
>      |               |             |               |              |
>      |               |             |               |              |
>      |               |             |               |              |
>      |-----|   |-----|             |-----|   |-----|              |
>            |   |                         |   |                    |
>            |   |                         |   |                    |
>         [0]|   |[1]                   [0]|   |[1]                 |
>       \-------------/               \-------------/        \------------/
>        \  FUNNEL0  /                 \  FUNNEL1  /          \  FUNNEL2  /
>         -----------                   -----------            -----------
>              |                             |                      |
>       \-------------/               \-------------/               |
>        \  FUNNEL3  /                 \  FUNNEL4  /                |
>         -----------                   -----------                 |
>            |  |                         |   |
>         [0]|  |[1]                   [0]|   |[1]                  |
>            |  |----------               |   |                     |
>            |            |               |   |                     |
>            |-------|    |      |------- |   |          |--------- |
>                    |    |      |            |          |
>                    |    |      |            |          |
>                 [0]|    |[1]   |[2]         |[3]       |[4]
>             \ ---------------------------------------------------/
>              \                     TPDA0                        /
>               \                                                /
>                ------------------------------------------------
> 
>>
>>> +    oneOf:
>>> +      - required:
>>> +          - port
>>> +      - required:
>>> +          - "#address-cells"
>>> +          - "#size-cells"
>>
>> The common schema that you removed handles this.
>>
>> Rob
>
Tingwei Zhang March 22, 2024, 10:22 a.m. UTC | #5
On 3/22/2024 5:42 PM, Suzuki K Poulose wrote:
> On 22/03/2024 07:02, Tingwei Zhang wrote:
>> On 3/21/2024 10:42 PM, Rob Herring wrote:
>>> On Thu, Mar 21, 2024 at 04:32:04PM +0800, Tao Zhang wrote:
>>>> Add new property "label" to label the source corresponding to the
>>>> output connection. When the funnel supports multi-output, this
>>>> property needs to be introduced to mark which source component a
>>>> certain output connection corresponds to.
>>>>
>>>> Signed-off-by: Tao Zhang <quic_taozha@quicinc.com>
>>>> ---
>>>>   .../arm/arm,coresight-dynamic-funnel.yaml     | 34 
>>>> ++++++++++++++++---
>>>>   1 file changed, 30 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git 
>>>> a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>>>> index 44a1041cb0fc..cde62c286d29 100644
>>>> --- 
>>>> a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>>>> +++ 
>>>> b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>>>> @@ -66,13 +66,39 @@ properties:
>>>>           $ref: /schemas/graph.yaml#/properties/port
>>>>     out-ports:
>>>> -    $ref: /schemas/graph.yaml#/properties/ports
>>>> -    additionalProperties: false
>>>> -
>>>> +    type: object
>>>>       properties:
>>>> +      "#address-cells":
>>>> +        const: 1
>>>> +
>>>> +      "#size-cells":
>>>> +        const: 0
>>>> +
>>>>         port:
>>>> +        type: object
>>>> +
>>>> +    patternProperties:
>>>> +      '^port(@[0-7])?$':
>>>> +        type: object
>>>>           description: Output connection to CoreSight Trace bus
>>>> -        $ref: /schemas/graph.yaml#/properties/port
>>>
>>> Nope, now you have no constraints on port node properties. Please look
>>> at how other bindings are done to add properties on endpoint node.
>>>
>> Thanks for pointing this out, Rob. Shall we ref port-base and
>> endpoint-base then add new properties on endpoint? In this way, the 
>> redundant code from port schema is not required.
>>>> +
>>>> +        patternProperties:
>>>> +          "^endpoint(@[0-9a-f]+)?$":
>>>> +            type: object
>>>> +            properties:
>>>> +              remote-endpoint:
>>>> +                description: |
>>>> +                  phandle to an 'endpoint' subnode of a remote 
>>>> device node.
>>>> +                  $ref: /schemas/types.yaml#/definitions/phandle
>>>
>>> Don't need this.
>>>
>>>> +              label:
>>>> +                description: Label the source corresponding to the 
>>>> output connection
>>>> +                $ref: /schemas/types.yaml#/definitions/string
>>>
>>> label already has a type.
>>>
>>> As this node is an output, aren't you labeling what the destination is,
>>> not the "source"?
>>>
>>> Why can't you look at the remote connection to identify what it is?
>>>
>> This funnel can route data stream from different trace source to 
>> different output ports. This lable property is added to describe which 
>> source is routed to this output port.
>>
>> For example, the graph is as below. Funnel3 routes trace data from 
>> TPDM0 to output[0] and output[0] of funnel3 is connected to input[0] 
>> of TPDA0.
> 
> Funnel3 and Funnel4 are really Replicators ! How are they Funnels ? 
> Again, my question still stands. Are Funnel(Replicator-renamed)3/4 and 
> Funnel 0/1/2 programmable ?

Sorry for oversimplied the topology. Funnel3 and Funnel4 have multiple 
input ports instead of just one input port. It can have multiple input 
ports and multiple output ports. Unlike replicator, it won't replicate 
same data trace to all the outputs.

Funnel3/funnel4 has same programing capability like standard coresight 
funnel. It can enable input ports as requested. It can not be programed 
to route which source to which output ports. Hardware staticlly defined 
which source is routed to which output.

> 
> Suzuki
> 
> 
>> While Funnels routes trace data from TPDM1 to output[1] which connects 
>> to input[1] of TPDA0. Hope that clarifies this a little bit.
>>
>> |---------|    |---------|    |---------|    |---------|    |---------|
>> |  TPDM0  |    |  TPDM1  |    |  TPDM2  |    |  TPDM3  |    |  TPDM4  |
>> |---------|    |---------|    |---------|    |---------|    |---------|
>>      |               |             |               |              |
>>      |               |             |               |              |
>>      |               |             |               |              |
>>      |-----|   |-----|             |-----|   |-----|              |
>>            |   |                         |   |                    |
>>            |   |                         |   |                    |
>>         [0]|   |[1]                   [0]|   |[1]                 |
>>       \-------------/               \-------------/        \------------/
>>        \  FUNNEL0  /                 \  FUNNEL1  /          \  FUNNEL2  /
>>         -----------                   -----------            -----------
>>              |                             |                      |
>>       \-------------/               \-------------/               |
>>        \  FUNNEL3  /                 \  FUNNEL4  /                |
>>         -----------                   -----------                 |
>>            |  |                         |   |
>>         [0]|  |[1]                   [0]|   |[1]                  |
>>            |  |----------               |   |                     |
>>            |            |               |   |                     |
>>            |-------|    |      |------- |   |          |--------- |
>>                    |    |      |            |          |
>>                    |    |      |            |          |
>>                 [0]|    |[1]   |[2]         |[3]       |[4]
>>             \ ---------------------------------------------------/
>>              \                     TPDA0                        /
>>               \                                                /
>>                ------------------------------------------------
>>
>>>
>>>> +    oneOf:
>>>> +      - required:
>>>> +          - port
>>>> +      - required:
>>>> +          - "#address-cells"
>>>> +          - "#size-cells"
>>>
>>> The common schema that you removed handles this.
>>>
>>> Rob
>>
>
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
index 44a1041cb0fc..cde62c286d29 100644
--- a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
+++ b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
@@ -66,13 +66,39 @@  properties:
         $ref: /schemas/graph.yaml#/properties/port
 
   out-ports:
-    $ref: /schemas/graph.yaml#/properties/ports
-    additionalProperties: false
-
+    type: object
     properties:
+      "#address-cells":
+        const: 1
+
+      "#size-cells":
+        const: 0
+
       port:
+        type: object
+
+    patternProperties:
+      '^port(@[0-7])?$':
+        type: object
         description: Output connection to CoreSight Trace bus
-        $ref: /schemas/graph.yaml#/properties/port
+
+        patternProperties:
+          "^endpoint(@[0-9a-f]+)?$":
+            type: object
+            properties:
+              remote-endpoint:
+                description: |
+                  phandle to an 'endpoint' subnode of a remote device node.
+                  $ref: /schemas/types.yaml#/definitions/phandle
+              label:
+                description: Label the source corresponding to the output connection
+                $ref: /schemas/types.yaml#/definitions/string
+    oneOf:
+      - required:
+          - port
+      - required:
+          - "#address-cells"
+          - "#size-cells"
 
 required:
   - compatible