1. Patchew
  2. linux
  3. [PATCH v2 00/12] Linux RISC-V trace framework and drivers
  4. View patch

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

Anup Patel posted 12 patches 3 months, 1 week ago
[PATCH v2 01/12] dt-bindings: Add RISC-V trace component bindings
Posted by Anup Patel 3 months, 1 week ago 
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@ventanamicro.com>
---
 .../bindings/riscv/riscv,trace-component.yaml | 112 ++++++++++++++++++
 1 file changed, 112 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..7979af3d4174
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/riscv,trace-component.yaml
@@ -0,0 +1,112 @@
+# 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@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. The type and version of a RISC-V trace component
+  can be discovered from it's IMPL memory mapped register hence component
+  specific compatible strings are not needed.
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - qemu,trace-component
+      - const: riscv,trace-component
+
+  reg:
+    maxItems: 1
+
+  cpus:
+    maxItems: 1
+    description:
+      phandle to the cpu to which the RISC-V trace component is bound.
+
+  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
+
+  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@c000000 {
+      compatible = "qemu,trace-component", "riscv,trace-component";
+      reg = <0xc000000 0x1000>;
+      cpus = <&CPU0>;
+      out-ports {
+        port {
+          CPU0_ENCODER_OUTPUT: endpoint {
+            remote-endpoint = <&CPU0_RAMSINK_INPUT>;
+          };
+        };
+      };
+    };
+
+    ramsink@c001000 {
+      compatible = "qemu,trace-component", "riscv,trace-component";
+      reg = <0xc001000 0x1000>;
+      cpus = <&CPU0>;
+      in-ports {
+        port {
+          CPU0_RAMSINK_INPUT: endpoint {
+          };
+        };
+      };
+    };
+
+    encoder@c002000 {
+      compatible = "qemu,trace-component", "riscv,trace-component";
+      reg = <0xc002000 0x1000>;
+      cpus = <&CPU1>;
+      out-ports {
+        port {
+          CPU1_ENCODER_OUTPUT: endpoint {
+            remote-endpoint = <&CPU1_RAMSINK_INPUT>;
+          };
+        };
+      };
+    };
+
+    ramsink@c003000 {
+      compatible = "qemu,trace-component", "riscv,trace-component";
+      reg = <0xc003000 0x1000>;
+      cpus = <&CPU1>;
+      in-ports {
+        port {
+          CPU1_RAMSINK_INPUT: endpoint {
+          };
+        };
+      };
+    };
+
+...
-- 
2.43.0
Re: [PATCH v2 01/12] dt-bindings: Add RISC-V trace component bindings
Posted by Rob Herring 2 months, 2 weeks ago 
On Sat, Nov 01, 2025 at 09:12:34PM +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@ventanamicro.com>
> ---
>  .../bindings/riscv/riscv,trace-component.yaml | 112 ++++++++++++++++++
>  1 file changed, 112 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..7979af3d4174
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/riscv/riscv,trace-component.yaml
> @@ -0,0 +1,112 @@
> +# 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@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. The type and version of a RISC-V trace component
> +  can be discovered from it's IMPL memory mapped register hence component
> +  specific compatible strings are not needed.
> +
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - qemu,trace-component
> +      - const: riscv,trace-component

'component' seems a bit redundant.

> +
> +  reg:
> +    maxItems: 1
> +
> +  cpus:
> +    maxItems: 1
> +    description:
> +      phandle to the cpu to which the RISC-V trace component is bound.
> +
> +  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
> +
> +  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

Is no in or out ports valid? If not, you need:

anyOf:
  - required: [ in-ports ]
  - required: [ out-ports ]

> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    // Example 1 (Per-hart encoder and ramsink components):
> +
> +    encoder@c000000 {

trace@...?

Node names should be generic and a given compatible should only have 1 
possible node name. (Yes, we failed to do this on Arm coresight stuff.)

> +      compatible = "qemu,trace-component", "riscv,trace-component";
> +      reg = <0xc000000 0x1000>;
> +      cpus = <&CPU0>;

blank line between properties and child nodes.

> +      out-ports {
> +        port {
> +          CPU0_ENCODER_OUTPUT: endpoint {
> +            remote-endpoint = <&CPU0_RAMSINK_INPUT>;
> +          };
> +        };
> +      };
> +    };
> +
> +    ramsink@c001000 {
> +      compatible = "qemu,trace-component", "riscv,trace-component";
> +      reg = <0xc001000 0x1000>;
> +      cpus = <&CPU0>;
> +      in-ports {
> +        port {
> +          CPU0_RAMSINK_INPUT: endpoint {
> +          };
> +        };
> +      };
> +    };
> +
> +    encoder@c002000 {
> +      compatible = "qemu,trace-component", "riscv,trace-component";
> +      reg = <0xc002000 0x1000>;
> +      cpus = <&CPU1>;
> +      out-ports {
> +        port {
> +          CPU1_ENCODER_OUTPUT: endpoint {
> +            remote-endpoint = <&CPU1_RAMSINK_INPUT>;
> +          };
> +        };
> +      };
> +    };
> +
> +    ramsink@c003000 {
> +      compatible = "qemu,trace-component", "riscv,trace-component";
> +      reg = <0xc003000 0x1000>;
> +      cpus = <&CPU1>;
> +      in-ports {
> +        port {
> +          CPU1_RAMSINK_INPUT: endpoint {
> +          };
> +        };
> +      };
> +    };
> +
> +...
> -- 
> 2.43.0
>
Re: [PATCH v2 01/12] dt-bindings: Add RISC-V trace component bindings
Posted by Anup Patel 1 month ago 
On Thu, Nov 20, 2025 at 10:09 PM Rob Herring <robh@kernel.org> wrote:
>
> On Sat, Nov 01, 2025 at 09:12:34PM +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@ventanamicro.com>
> > ---
> >  .../bindings/riscv/riscv,trace-component.yaml | 112 ++++++++++++++++++
> >  1 file changed, 112 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..7979af3d4174
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/riscv/riscv,trace-component.yaml
> > @@ -0,0 +1,112 @@
> > +# 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@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. The type and version of a RISC-V trace component
> > +  can be discovered from it's IMPL memory mapped register hence component
> > +  specific compatible strings are not needed.
> > +
> > +properties:
> > +  compatible:
> > +    items:
> > +      - enum:
> > +          - qemu,trace-component
> > +      - const: riscv,trace-component
>
> 'component' seems a bit redundant.

The RISC-V trace control specification refers to MMIO trace
devices as 'components' hence we should keep the 'component'
name in the compatible string.

>
> > +
> > +  reg:
> > +    maxItems: 1
> > +
> > +  cpus:
> > +    maxItems: 1
> > +    description:
> > +      phandle to the cpu to which the RISC-V trace component is bound.
> > +
> > +  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
> > +
> > +  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
>
> Is no in or out ports valid? If not, you need:
>
> anyOf:
>   - required: [ in-ports ]
>   - required: [ out-ports ]

Trace component with no in or out port is invalid
so I will include the above "anyOf" snippet in the
next revision.

>
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > +  - |
> > +    // Example 1 (Per-hart encoder and ramsink components):
> > +
> > +    encoder@c000000 {
>
> trace@...?

Okay, I will update.

>
> Node names should be generic and a given compatible should only have 1
> possible node name. (Yes, we failed to do this on Arm coresight stuff.)
>
> > +      compatible = "qemu,trace-component", "riscv,trace-component";
> > +      reg = <0xc000000 0x1000>;
> > +      cpus = <&CPU0>;
>
> blank line between properties and child nodes.

Okay, I will update.

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

Regards,
Anup

Patchew 2.1-devel-b67e4c2

© 2016 - 2026 Red Hat, Inc.