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 | 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@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
+
+ reg:
+ maxItems: 1
+
+ cpu:
+ description:
+ phandle to the cpu to which the RISC-V trace component is bound.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ 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>;
+ cpu = <&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>;
+ cpu = <&CPU0>;
+ in-ports {
+ port {
+ CPU0_RAMSINK_INPUT: endpoint {
+ };
+ };
+ };
+ };
+
+ encoder@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@c003000 {
+ compatible = "qemu,trace-component", "riscv,trace-component";
+ reg = <0xc003000 0x1000>;
+ cpu = <&CPU1>;
+ in-ports {
+ port {
+ CPU1_RAMSINK_INPUT: endpoint {
+ };
+ };
+ };
+ };
+
+...
--
2.43.0On 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@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@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.
> +
> + reg:
> + maxItems: 1
> +
> + cpu:
'cpus' is the more standard property.
> + 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.
> +
> + 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.
> +
> + 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 {
Perhaps it is time to standardize the node names here. Perhaps 'trace'.
> + 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@c001000 {
> + compatible = "qemu,trace-component", "riscv,trace-component";
> + reg = <0xc001000 0x1000>;
> + cpu = <&CPU0>;
> + in-ports {
> + port {
> + CPU0_RAMSINK_INPUT: endpoint {
> + };
> + };
> + };
> + };
> +
> + encoder@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@c003000 {
> + compatible = "qemu,trace-component", "riscv,trace-component";
> + reg = <0xc003000 0x1000>;
> + cpu = <&CPU1>;
> + in-ports {
> + port {
> + CPU1_RAMSINK_INPUT: endpoint {
> + };
> + };
> + };
> + };
> +
> +...
> --
> 2.43.0
>
Hi Rob,
Apologies for the delayed response ...
On Fri, Oct 3, 2025 at 12:55 AM Rob Herring <robh@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@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@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@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@c001000 {
> > + compatible = "qemu,trace-component", "riscv,trace-component";
> > + reg = <0xc001000 0x1000>;
> > + cpu = <&CPU0>;
> > + in-ports {
> > + port {
> > + CPU0_RAMSINK_INPUT: endpoint {
> > + };
> > + };
> > + };
> > + };
> > +
> > + encoder@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@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
© 2016 - 2025 Red Hat, Inc.