All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Anup Patel <apatel@ventanamicro.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Ian Rogers <irogers@google.com>,
	Atish Patra <atish.patra@linux.dev>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
	Liang Kan <kan.liang@linux.intel.com>,
	Alexandre Ghiti <alex@ghiti.fr>, Anup Patel <anup@brainfault.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Jones <ajones@ventanamicro.com>,
	devicetree@vger.kernel.org, Conor Dooley <conor+dt@kernel.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Mayuresh Chitale <mchitale@gmail.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Palmer Dabbelt <palmer@dabbelt.com>, Jiri Olsa <jolsa@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>
Subject: Re: [PATCH 01/11] dt-bindings: Add RISC-V trace component bindings
Date: Thu, 2 Oct 2025 14:25:06 -0500	[thread overview]
Message-ID: <20251002192506.GA236729-robh@kernel.org> (raw)
In-Reply-To: <20251002060732.100213-2-apatel@ventanamicro.com>

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.

> +
> +  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
> 

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Anup Patel <apatel@ventanamicro.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Ian Rogers <irogers@google.com>, Alexandre Ghiti <alex@ghiti.fr>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>, Jiri Olsa <jolsa@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Liang Kan <kan.liang@linux.intel.com>,
	Mayuresh Chitale <mchitale@gmail.com>,
	Anup Patel <anup@brainfault.org>,
	Atish Patra <atish.patra@linux.dev>,
	Andrew Jones <ajones@ventanamicro.com>,
	Sunil V L <sunilvl@ventanamicro.com>,
	linux-riscv@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/11] dt-bindings: Add RISC-V trace component bindings
Date: Thu, 2 Oct 2025 14:25:06 -0500	[thread overview]
Message-ID: <20251002192506.GA236729-robh@kernel.org> (raw)
In-Reply-To: <20251002060732.100213-2-apatel@ventanamicro.com>

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.

> +
> +  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
> 

  reply	other threads:[~2025-10-02 19:25 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-02  6:07 [PATCH 00/11] Linux RISC-V trace framework and drivers Anup Patel
2025-10-02  6:07 ` Anup Patel
2025-10-02  6:07 ` [PATCH 01/11] dt-bindings: Add RISC-V trace component bindings Anup Patel
2025-10-02  6:07   ` Anup Patel
2025-10-02 19:25   ` Rob Herring [this message]
2025-10-02 19:25     ` Rob Herring
2025-10-09 13:34     ` Anup Patel
2025-10-09 13:34       ` Anup Patel
2025-10-02  6:07 ` [PATCH 02/11] rvtrace: Initial implementation of driver framework Anup Patel
2025-10-02  6:07   ` Anup Patel
2025-10-11  1:07   ` Bo Gan
2025-10-11  1:07     ` Bo Gan
2025-10-30  8:37     ` Anup Patel
2025-10-30  8:37       ` Anup Patel
2026-01-21  7:50   ` Vincent Chen
2026-01-21  7:50     ` Vincent Chen
2026-01-26 13:36     ` Anup Patel
2026-01-26 13:36       ` Anup Patel
2026-01-27 12:19       ` Bo Gan
2026-01-27 12:19         ` Bo Gan
2026-03-13  2:10         ` Vincent Chen
2026-03-13  2:10           ` Vincent Chen
2025-10-02  6:07 ` [PATCH 03/11] rvtrace: Add functions to create/destroy a trace component path Anup Patel
2025-10-02  6:07   ` Anup Patel
2025-10-02  6:07 ` [PATCH 04/11] rvtrace: Add functions to start/stop tracing on a " Anup Patel
2025-10-02  6:07   ` Anup Patel
2025-10-08  9:13   ` Bo Gan
2025-10-08  9:13     ` Bo Gan
2025-10-13  3:43     ` Anup Patel
2025-10-13  3:43       ` Anup Patel
2025-10-13  4:52       ` Bo Gan
2025-10-13  4:52         ` Bo Gan
2025-10-14  8:10         ` Mayuresh Chitale
2025-10-14  8:10           ` Mayuresh Chitale
2025-10-14  8:59           ` Bo Gan
2025-10-14  8:59             ` Bo Gan
2025-10-02  6:07 ` [PATCH 05/11] rvtrace: Add trace encoder driver Anup Patel
2025-10-02  6:07   ` Anup Patel
2025-10-07  7:09   ` Bo Gan
2025-10-07  7:09     ` Bo Gan
2025-10-08  8:48     ` Bo Gan
2025-10-08  8:48       ` Bo Gan
     [not found]       ` <CAN37VV7uBkRzYsQcgGtw_iFg=za91OH7_1OSJ+b8eeuCzL5iDw@mail.gmail.com>
2025-10-08  9:51         ` Bo Gan
2025-10-08  9:51           ` Bo Gan
2025-10-02  6:07 ` [PATCH 06/11] rvtrace: Add function to copy into perf AUX buffer Anup Patel
2025-10-02  6:07   ` Anup Patel
2025-10-02  6:07 ` [PATCH 07/11] rvtrace: Add trace ramsink driver Anup Patel
2025-10-02  6:07   ` Anup Patel
2025-10-07  7:49   ` Bo Gan
2025-10-07  7:49     ` Bo Gan
     [not found]     ` <CAN37VV5J2+gzpraR2NhaJBNfQ3dPsr-72Mmg03+ykcLoouZ8_Q@mail.gmail.com>
2025-10-11  0:41       ` Bo Gan
2025-10-11  0:41         ` Bo Gan
2025-10-13 13:38         ` Mayuresh Chitale
2025-10-13 13:38           ` Mayuresh Chitale
2025-10-02  6:07 ` [PATCH 08/11] rvtrace: Add perf driver for tracing using perf tool Anup Patel
2025-10-02  6:07   ` Anup Patel
2025-10-02  6:07 ` [PATCH 09/11] perf tools: Add RISC-V trace PMU record capabilities Anup Patel
2025-10-02  6:07   ` Anup Patel
2025-10-02  6:07 ` [PATCH 10/11] perf tools: Initial support for RISC-V trace decoder Anup Patel
2025-10-02  6:07   ` Anup Patel
2025-10-02  6:07 ` [PATCH 11/11] MAINTAINERS: Add entry for RISC-V trace framework and drivers Anup Patel
2025-10-02  6:07   ` Anup Patel
2025-10-02  6:26 ` [PATCH 00/11] Linux " Greg KH
2025-10-02  6:26   ` Greg KH
2025-10-02  6:39   ` Anup Patel
2025-10-02  6:39     ` Anup Patel
2025-10-02  6:44     ` Greg KH
2025-10-02  6:44       ` Greg KH
2025-10-02 20:42       ` Bo Gan
2025-10-02 20:42         ` Bo Gan
2025-10-03  4:15         ` Anup Patel
2025-10-03  4:15           ` Anup Patel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251002192506.GA236729-robh@kernel.org \
    --to=robh@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=ajones@ventanamicro.com \
    --cc=alex@ghiti.fr \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=anup@brainfault.org \
    --cc=apatel@ventanamicro.com \
    --cc=atish.patra@linux.dev \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=mchitale@gmail.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.