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

[Suzuki K Poulose]

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 at 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
>