Re: [PATCH v4 15/19] dts: bindings: Document device tree bindings for ETE

From: Rob Herring <robh@kernel.org>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Mike Leach <mike.leach@linaro.org>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Leo Yan <leo.yan@linaro.org>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v4 15/19] dts: bindings: Document device tree bindings for ETE
Date: Mon, 22 Mar 2021 11:28:30 -0600	[thread overview]
Message-ID: <CAL_JsqL6ZQPFqc_Q4A6cB+8d7eGidoFhvJwa_YrZm-Xz7oC6mQ@mail.gmail.com> (raw)
In-Reply-To: <f69ad530-baec-2e73-827a-b5a5a6df3d23@arm.com>

On Mon, Mar 22, 2021 at 10:53 AM Suzuki K Poulose
<suzuki.poulose@arm.com> wrote:
>
> Hi Rob
>
> On 06/03/2021 21:06, Rob Herring wrote:
> > On Thu, Feb 25, 2021 at 07:35:39PM +0000, Suzuki K Poulose wrote:
> >> Document the device tree bindings for Embedded Trace Extensions.
> >> ETE can be connected to legacy coresight components and thus
> >> could optionally contain a connection graph as described by
> >> the CoreSight bindings.
> >>
> >> Cc: devicetree@vger.kernel.org
> >> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> >> Cc: Mike Leach <mike.leach@linaro.org>
> >> Cc: Rob Herring <robh@kernel.org>
> >> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> >> ---
> >> Changes:
> >>   - Fix out-ports defintion
> >> ---
> >>   .../devicetree/bindings/arm/ete.yaml          | 71 +++++++++++++++++++
> >>   1 file changed, 71 insertions(+)
> >>   create mode 100644 Documentation/devicetree/bindings/arm/ete.yaml
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/ete.yaml b/Documentation/devicetree/bindings/arm/ete.yaml
> >> new file mode 100644
> >> index 000000000000..35a42d92bf97
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/arm/ete.yaml
> >> @@ -0,0 +1,71 @@
> >> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
> >> +# Copyright 2021, Arm Ltd
> >> +%YAML 1.2
> >> +---
> >> +$id: "http://devicetree.org/schemas/arm/ete.yaml#"
> >> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> >> +
> >> +title: ARM Embedded Trace Extensions
> >> +
> >> +maintainers:
> >> +  - Suzuki K Poulose <suzuki.poulose@arm.com>
> >> +  - Mathieu Poirier <mathieu.poirier@linaro.org>
> >> +
> >> +description: |
> >> +  Arm Embedded Trace Extension(ETE) is a per CPU trace component that
> >> +  allows tracing the CPU execution. It overlaps with the CoreSight ETMv4
> >> +  architecture and has extended support for future architecture changes.
> >> +  The trace generated by the ETE could be stored via legacy CoreSight
> >> +  components (e.g, TMC-ETR) or other means (e.g, using a per CPU buffer
> >> +  Arm Trace Buffer Extension (TRBE)). Since the ETE can be connected to
> >> +  legacy CoreSight components, a node must be listed per instance, along
> >> +  with any optional connection graph as per the coresight bindings.
> >> +  See bindings/arm/coresight.txt.
> >> +
> >> +properties:
> >> +  $nodename:
> >> +    pattern: "^ete([0-9a-f]+)$"
> >> +  compatible:
> >> +    items:
> >> +      - const: arm,embedded-trace-extension
> >> +
> >> +  cpu:
> >> +    description: |
> >> +      Handle to the cpu this ETE is bound to.
> >> +    $ref: /schemas/types.yaml#/definitions/phandle
> >> +
> >> +  out-ports:
> >> +    description: |
> >> +      Output connections from the ETE to legacy CoreSight trace bus.
> >> +    $ref: /schemas/graph.yaml#/properties/port
> >
> > s/port/ports/
>
> Ok.
>
> >
> > And then you need:
> >
> >         properties:
> >           port:
> >             description: what this port is
> >             $ref: /schemas/graph.yaml#/properties/port
>
> Isn't this already covered by the definition of ports ? There are no
> fixed connections for ETE. It is optional and could be connected to
> any legacy CoreSight component. i.e, a "ports" object can have port
> objects inside.

'properties/ports' only defines that you have 'port' nodes within it.

> Given we have defined out-ports as an object "confirming to the ports"
> do we need to describe the individual port nodes ?

Yes, you have to define what the 'port' nodes are. A port is a data
stream and you should know what your hardware has. What the data
stream is connected to is outside the scope of the binding.

Rob