[PATCH 01/11] dt-bindings: Add RISC-V trace component bindings

[Anup Patel]

Hi Rob,

Apologies for the delayed response ...

On Fri, Oct 3, 2025 at 12:55 AM Rob Herring <robh at kernel.org> wrote:
>
> On Thu, Oct 02, 2025 at 11:37:22AM +0530, Anup Patel wrote:
> > Add device tree bindings for the memory mapped RISC-V trace components
> > which support both the RISC-V efficient trace (E-trace) protocol and
> > the RISC-V Nexus-based trace (N-trace) protocol.
> >
> > The RISC-V trace components are defined by the RISC-V trace control
> > interface specification.
> >
> > Signed-off-by: Anup Patel <apatel at ventanamicro.com>
> > ---
> >  .../bindings/riscv/riscv,trace-component.yaml | 110 ++++++++++++++++++
> >  1 file changed, 110 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/riscv/riscv,trace-component.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/riscv/riscv,trace-component.yaml b/Documentation/devicetree/bindings/riscv/riscv,trace-component.yaml
> > new file mode 100644
> > index 000000000000..78a70fe04dfe
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/riscv/riscv,trace-component.yaml
> > @@ -0,0 +1,110 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/riscv/riscv,trace-component.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: RISC-V Trace Component
> > +
> > +maintainers:
> > +  - Anup Patel <anup at brainfault.org>
> > +
> > +description:
> > +  The RISC-V trace control interface specification standard memory mapped
> > +  components (or devices) which support both the RISC-V efficient trace
> > +  (E-trace) protocol and the RISC-V Nexus-based trace (N-trace) protocol.
> > +  The RISC-V trace components have implementation specific directed acyclic
> > +  graph style interdependency where output of one component serves as input
> > +  to another component and certain components (such as funnel) can take inputs
> > +  from multiple components.
> > +
> > +properties:
> > +  compatible:
> > +    items:
> > +      - enum:
> > +          - qemu,trace-component
> > +      - const: riscv,trace-component
>
> Given the generic-ness of these names, I'm assuming the exact type of
> component is discoverable. I don't like to assume things in bindings, so
> spell that out.
>
> Is the implementer discoverable? If so, you could omit the 1st
> compatible.

The component type and component version is discoverable through
read-only MMIO registers but the implementer of the component
needs to be inferred using implementation specific compatible string.
I will add some text along these lines in the above description.

>
> > +
> > +  reg:
> > +    maxItems: 1
> > +
> > +  cpu:
>
> 'cpus' is the more standard property.

Okay, I will update.

>
> > +    description:
> > +      phandle to the cpu to which the RISC-V trace component is bound.
> > +    $ref: /schemas/types.yaml#/definitions/phandle
>
> which already has a type. So just 'maxItems: 1' here.

Okay, I will update.

>
> > +
> > +  in-ports:
> > +    $ref: /schemas/graph.yaml#/properties/ports
> > +    patternProperties:
> > +      '^port(@[0-7])?$':
> > +        description: Input connections from RISC-V trace component
> > +        $ref: /schemas/graph.yaml#/properties/port
>
> If the N ports are N of the same data (like a mux), then fine. If each
> port is different, then you need to define what each port is.

Yes, the data (aka trace packets) is the same for all input trace ports
even in-case of funnel (aka mux). Same thing also applies to the
output ports.

>
> > +
> > +  out-ports:
> > +    $ref: /schemas/graph.yaml#/properties/ports
> > +    patternProperties:
> > +      '^port(@[0-7])?$':
> > +        description: Output connections from RISC-V trace component
> > +        $ref: /schemas/graph.yaml#/properties/port
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > +  - |
> > +    // Example 1 (Per-hart encoder and ramsink components):
> > +
> > +    encoder at c000000 {
>
> Perhaps it is time to standardize the node names here. Perhaps 'trace'.

It is better to not fix the node names because this allows users
to infer type of component from node name hence more human
readable.

>
> > +      compatible = "qemu,trace-component", "riscv,trace-component";
> > +      reg = <0xc000000 0x1000>;
> > +      cpu = <&CPU0>;
> > +      out-ports {
> > +        port {
> > +          CPU0_ENCODER_OUTPUT: endpoint {
> > +            remote-endpoint = <&CPU0_RAMSINK_INPUT>;
> > +          };
> > +        };
> > +      };
> > +    };
> > +
> > +    ramsink at c001000 {
> > +      compatible = "qemu,trace-component", "riscv,trace-component";
> > +      reg = <0xc001000 0x1000>;
> > +      cpu = <&CPU0>;
> > +      in-ports {
> > +        port {
> > +          CPU0_RAMSINK_INPUT: endpoint {
> > +          };
> > +        };
> > +      };
> > +    };
> > +
> > +    encoder at c002000 {
> > +      compatible = "qemu,trace-component", "riscv,trace-component";
> > +      reg = <0xc002000 0x1000>;
> > +      cpu = <&CPU1>;
> > +      out-ports {
> > +        port {
> > +          CPU1_ENCODER_OUTPUT: endpoint {
> > +            remote-endpoint = <&CPU1_RAMSINK_INPUT>;
> > +          };
> > +        };
> > +      };
> > +    };
> > +
> > +    ramsink at c003000 {
> > +      compatible = "qemu,trace-component", "riscv,trace-component";
> > +      reg = <0xc003000 0x1000>;
> > +      cpu = <&CPU1>;
> > +      in-ports {
> > +        port {
> > +          CPU1_RAMSINK_INPUT: endpoint {
> > +          };
> > +        };
> > +      };
> > +    };
> > +
> > +...
> > --
> > 2.43.0
> >

Regards,
Anup