lkml.org 
[lkml]   [2024]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 1/4] dt-bindings: arm: qcom,coresight-funnel: Add label for multi-ouput
From
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
>


\
 
 \ /
  Last update: 2024-05-27 15:59    [W:1.398 / U:1.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site