Messages in this thread | | | Date | Fri, 22 Mar 2024 09:42:54 +0000 | Subject | Re: [PATCH 1/4] dt-bindings: arm: qcom,coresight-funnel: Add label for multi-ouput | From | 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@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 >
| |