On Mon, Mar 22, 2021 at 10:53 AM Suzuki K Poulose <suzuki.poul...@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: devicet...@vger.kernel.org > >> Cc: Mathieu Poirier <mathieu.poir...@linaro.org> > >> Cc: Mike Leach <mike.le...@linaro.org> > >> Cc: Rob Herring <r...@kernel.org> > >> Signed-off-by: Suzuki K Poulose <suzuki.poul...@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.poul...@arm.com> > >> + - Mathieu Poirier <mathieu.poir...@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
