[PATCH v2 2/3] dt-bindings: arm: Add Coresight Dummy Trace YAML schema

[Hao Zhang]

Hi Rob,

On 4/1/2023 2:47 AM, Rob Herring wrote:
> On Fri, Mar 24, 2023 at 02:16:07PM +0800, Hao Zhang wrote:
>> Add new coresight-dummy.yaml file describing the bindings required
>> to define coresight dummy trace in the device trees.
> 
> The diff tells me all this. Please explain why this is needed and needs
> to be in DT here.
> 
Sure, will add more details to describe it.
>>
>> Signed-off-by: Hao Zhang <quic_hazha at quicinc.com>
>> ---
>>   .../bindings/arm/qcom,coresight-dummy.yaml    | 118 ++++++++++++++++++
>>   1 file changed, 118 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-dummy.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-dummy.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-dummy.yaml
>> new file mode 100644
>> index 000000000000..7b719b084d72
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-dummy.yaml
>> @@ -0,0 +1,118 @@
>> +# 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-dummy.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: QCOM Coresight Dummy component
>> +
>> +description: |
>> +  The Coresight Dummy component is for the specific devices that HLOS don't have
>> +  permission to access or configure. Such as Coresight sink EUD, some TPDMs etc.
> 
> EUD? TPDM?

The term EUD stand for Embedded USB debugger, it will be connected to 
coresight replicator component to receive and store coresight data. It 
would be configured by NON-HLOS, and need HLOS(Kernel) to configure the 
last coresight components. So we will use dummy sink to replace it in 
kernel side for building the whole path(from source to sink).

The TPDM is Trace Profiling and Diagnostics Monitor, it is a coresight 
trace source which could get hardware events from the IP subsystem.

> 
> I don't really love 'dummy' used here. Maybe the OS still wants/needs to
> know where the sink goes to even if not configurable.
> 
> You *can* have multiple compatibles for a single generic driver if those
> compatibles might be useful some day.
> 

Yes, we want to take it as a generic framework for coresight dummy sink 
and source. I think we could add one more compatible to indicate the 
type of it.

>> +  So there need driver to register dummy devices as Coresight devices. Provide
>> +  Coresight API for dummy device operations, such as enabling and disabling
>> +  dummy devices. Build the Coresight path for dummy sink or dummy source for
>> +  debugging.
>> +
>> +  The primary use case of the coresight dummy is to build path for dummy sink or
>> +  dummy source.
>> +
>> +maintainers:
>> +  - Mao Jinlong <quic_jinlmao at quicinc.com>
>> +  - Tao Zhang <quic_taozha at quicinc.com>
>> +  - Hao Zhang <quic_hazha at quicinc.com>
>> +
>> +select:
>> +  properties:
>> +    compatible:
>> +      contains:
>> +        enum:
>> +          - qcom,coresight-dummy
>> +  required:
>> +    - compatible
>> +
>> +properties:
>> +  $nodename:
>> +    pattern: "^dummy_.*(sink|source)_[0-9]+.*$"
> 
> Don't use '_' in node names.
> 
> Convention for multiple instances without 'reg' is '-[0-9]+' on the end,
> but you are allowing anything after that.
> 

OK, I will update it in the next version of patch.

>> +  compatible:
>> +    items:
>> +      - const: qcom,coresight-dummy
>> +
>> +  qcom,dummy-sink:
>> +    type: boolean
>> +    description:
>> +      Indicates that the type of this coresight node is dummy sink.
>> +
>> +  qcom,dummy-source:
> 
> Incorporate source or sink into the compatible strings.
> 

OK, I will update it in the next version of patch.

> It's also somewhat redundant with 'in-ports' vs. 'out-ports'.

I think I could add more details to describe it.

> 
>> +    type: boolean
>> +    description:
>> +      Indicates that the type of this coresight node is dummy source.
>> +
>> +  out-ports:
>> +    description: |
> 
> Don't need '|' unless you need to preserve formatting.

I will remove it.

Thanks for your comments, I will take your advice and update it in the 
next version of patch.

Thanks,
Hao

> 
>> +      Output connections from the dummy source to Coresight Trace bus.
>> +    $ref: /schemas/graph.yaml#/properties/ports
>> +
>> +    properties:
>> +      port:
>> +        description: Output connection from the dummy source to Coresight
>> +            Trace bus.
>> +        $ref: /schemas/graph.yaml#/properties/port
>> +
>> +  in-ports:
>> +    description: |
>> +      Input connections from the CoreSight Trace bus to dummy sink.
>> +    $ref: /schemas/graph.yaml#/properties/ports
>> +
>> +    properties:
>> +      port:
>> +        description: Input connection from the Coresight Trace bus to
>> +            dummy sink.
>> +        $ref: /schemas/graph.yaml#/properties/port
>> +
>> +required:
>> +  - compatible
>> +
>> +additionalProperties: false
>> +
>> +oneOf:
>> +  - required:
>> +      - qcom,dummy-sink
>> +  - required:
>> +      - qcom,dummy-source
>> +
>> +examples:
>> +  # minimum dummy sink definition. dummy sink connect to coresight replicator.
>> +  - |
>> +    dummy_sink_1 {
>> +      compatible = "qcom,coresight-dummy";
>> +      qcom,dummy-sink;
>> +
>> +      in-ports {
>> +        port {
>> +          eud_in_replicator_swao: endpoint {
>> +            remote-endpoint =
>> +              <&replicator_swao_out_eud>;
>> +          };
>> +        };
>> +      };
>> +    };
>> +
>> +  # minimum dummy source definition. dummy source connect to coresight funnel.
>> +  - |
>> +    dummy_source_1 {
>> +      compatible = "qcom,coresight-dummy";
>> +      qcom,dummy-source;
>> +
>> +      out-ports {
>> +        port {
>> +          dummy_riscv_out_funnel_swao: endpoint {
>> +            remote-endpoint =
>> +              <&funnel_swao_in_dummy_riscv>;
>> +          };
>> +        };
>> +      };
>> +    };
>> +
>> +...
>> -- 
>> 2.17.1
>>