On Tue, Jan 7, 2020 at 10:11 AM Mike Leach <mike.leach@xxxxxxxxxx> wrote: > > Hi Rob, > > Thanks for the feedback. > > On Fri, 3 Jan 2020 at 22:24, Rob Herring <robh@xxxxxxxxxx> wrote: > > > > On Mon, Dec 30, 2019 at 04:41:37PM +0000, Mike Leach wrote: > > > Adds new coresight-cti.yaml file describing the bindings required to define > > > CTI in the device trees. > > > > > > Adds an include file to dt-bindings/arm to define constants describing > > > common signal functionality used in CoreSight and generic usage. > > > > What's going on with the message threading in this series? > > > > Not entirely sure what is expected here. TL;DR: what git-send-email defaults to. Each message should set 'in-reply-to' to the 1st message. > > > Signed-off-by: Mike Leach <mike.leach@xxxxxxxxxx> > > > Reviewed-by: Mathieu Poirier <mathieu.poirier@xxxxxxxxxx> > > > Reviewed-by: Suzuki K Poulose <suzuki.poulose@xxxxxxx> > > > --- > > > .../bindings/arm/coresight-cti.yaml | 326 ++++++++++++++++++ > > > .../devicetree/bindings/arm/coresight.txt | 7 + > > > MAINTAINERS | 2 + > > > include/dt-bindings/arm/coresight-cti-dt.h | 37 ++ > > > 4 files changed, 372 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/arm/coresight-cti.yaml > > > create mode 100644 include/dt-bindings/arm/coresight-cti-dt.h > > > > > > diff --git a/Documentation/devicetree/bindings/arm/coresight-cti.yaml b/Documentation/devicetree/bindings/arm/coresight-cti.yaml > > > new file mode 100644 > > > index 000000000000..e4d28cee5dfd > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/arm/coresight-cti.yaml > > > @@ -0,0 +1,326 @@ > > > +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause > > > +# Copyright 2019 Linaro Ltd. > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/arm/coresight-cti.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: ARM Coresight Cross Trigger Interface (CTI) device. > > > + > > > +description: | > > > + The CoreSight Embedded Cross Trigger (ECT) consists of CTI devices connected > > > + to one or more CoreSight components and/or a CPU, with CTIs interconnected in > > > + a star topology via the Cross Trigger Matrix (CTM), which is not programmable. > > > + The ECT components are not part of the trace generation data path and are thus > > > + not part of the CoreSight graph described in the general CoreSight bindings > > > + file coresight.txt. > > > + > > > + The CTI component properties define the connections between the individual > > > + CTI and the components it is directly connected to, consisting of input and > > > + output hardware trigger signals. CTIs can have a maximum number of input and > > > + output hardware trigger signals (8 each for v1 CTI, 32 each for v2 CTI). The > > > + number is defined at design time, the maximum of each defined in the DEVID > > > + register. > > > + > > > + CTIs are interconnected in a star topology via the CTM, using a number of > > > + programmable channels, usually 4, but again implementation defined and > > > + described in the DEVID register. The star topology is not required to be > > > + described in the bindings as the actual connections are software > > > + programmable. > > > + > > > + In general the connections between CTI and components via the trigger signals > > > + are implementation defined, except when the CTI is connected to an ARM v8 > > > + architecture core and optional ETM. > > > + > > > + In this case the ARM v8 architecture defines the required signal connections > > > + between CTI and the CPU core and ETM if present. In the case of a v8 > > > + architecturally connected CTI an additional compatible string is used to > > > + indicate this feature (arm,coresight-cti-v8-arch). > > > + > > > + When CTI trigger connection information is unavailable then a minimal driver > > > + binding can be declared with no explicit trigger signals. This will result > > > + the driver detecting the maximum available triggers and channels from the > > > + DEVID register and make them all available for use as a single default > > > + connection. Any user / client application will require additional information > > > + on the connections between the CTI and other components for correct operation. > > > + This information might be found by enabling the Integration Test registers in > > > + the driver (set CONFIG_CORESIGHT_CTI_INTEGRATION_TEST in Kernel > > > + configuration). These registers may be used to explore the trigger connections > > > + between CTI and other CoreSight components. > > > + > > > + Certain triggers between CoreSight devices and the CTI have specific types > > > + and usages. These can be defined along with the signal indexes with the > > > + constants defined in <dt-bindings/arm/coresight-cti-dt.h> > > > + > > > + For example a CTI connected to a core will usually have a DBGREQ signal. This > > > + is defined in the binding as type PE_EDBGREQ. These types will appear in an > > > + optional array alongside the signal indexes. Omitting types will default all > > > + signals to GEN_IO. > > > + > > > + Note that some hardware trigger signals can be connected to non-CoreSight > > > + components (e.g. UART etc) depending on hardware implementation. > > > + > > > +maintainers: > > > + - Mike Leach <mike.leach@xxxxxxxxxx> > > > + > > > +allOf: > > > + - $ref: /schemas/arm/primecell.yaml# > > > + > > > +# Need a custom select here or 'arm,primecell' will match on lots of nodes > > > +select: > > > + properties: > > > + compatible: > > > + contains: > > > + enum: > > > + - arm,coresight-cti > > > + required: > > > + - compatible > > > + > > > +properties: > > > + $nodename: > > > + pattern: "^cti(@[0-9a-f]+)$" > > > + compatible: > > > + oneOf: > > > + - items: > > > + - const: arm,coresight-cti > > > + - const: arm,primecell > > > + - items: > > > + - const: arm,coresight-cti-v8-arch > > > + - const: arm,coresight-cti > > > + - const: arm,primecell > > > + > > > + reg: > > > + maxItems: 1 > > > + > > > + cpu: > > > + $ref: /schemas/types.yaml#/definitions/phandle > > > + description: > > > + Handle to cpu this device is associated with. This must appear in the > > > + base cti node if compatible string arm,coresight-cti-v8-arch is used, > > > + or may appear in a trig-conns child node when appropriate. > > > + > > > + arm,cti-ctm-id: > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > + description: > > > + Defines the CTM this CTI is connected to, in large systems with multiple > > > + separate CTI/CTM nets. Typically multi-socket systems where the CTM is > > > + propagated between sockets. > > > + > > > + arm,cs-dev-assoc: > > > + $ref: /schemas/types.yaml#/definitions/phandle > > > + description: > > > + defines a phandle reference to an associated CoreSight trace device. > > > + When the associated trace device is enabled, then the respective CTI > > > + will be enabled. Use in a trig-conns node, or in CTI base node when > > > + compatible string arm,coresight-cti-v8-arch used. If the associated > > > + device has not been registered then the node name will be stored as > > > + the connection name for later resolution. If the associated device is > > > + not a CoreSight device or not registered then the node name will remain > > > + the connection name and automatic enabling will not occur. > > > + > > > +patternProperties: > > > + '^trig-conns@([0-9]+)$': > > > + type: object > > > + description: > > > + A trigger connections child node which describes the trigger signals > > > + between this CTI and another hardware device. This device may be a CPU, > > > + CoreSight device, any other hardware device or simple external IO lines. > > > + The connection may have both input and output triggers, or only one or the > > > + other. > > > + > > > + properties: > > > + > > > + arm,trig-in-sigs: > > > + allOf: > > > + - $ref: /schemas/types.yaml#/definitions/uint32-array > > > + minItems: 1 > > > + maxItems: 32 > > > + description: > > > + List of CTI trigger in signal numbers in use by a trig-conns node. > > > + > > > + arm,trig-in-types: > > > + allOf: > > > + - $ref: /schemas/types.yaml#/definitions/uint32-array > > > + minItems: 1 > > > + maxItems: 32 > > > + description: > > > + List of constants representing the types for the CTI trigger in > > > + signals. Types in this array match to the corresponding signal in the > > > + arm,trig-in-sigs array. If the -types array is smaller, or omitted > > > + completely, then the types will default to GEN_IO. > > > + > > > + arm,trig-out-sigs: > > > + allOf: > > > + - $ref: /schemas/types.yaml#/definitions/uint32-array > > > + minItems: 1 > > > + maxItems: 32 > > > + description: > > > + List of CTI trigger out signal numbers in use by a trig-conns node. > > > + > > > + arm,trig-out-types: > > > + allOf: > > > + - $ref: /schemas/types.yaml#/definitions/uint32-array > > > + minItems: 1 > > > + maxItems: 32 > > > + description: > > > + List of constants representing the types for the CTI trigger out > > > + signals. Types in this array match to the corresponding signal > > > + in the arm,trig-out-sigs array. If the "-types" array is smaller, > > > + or omitted completely, then the types will default to GEN_IO. > > > + > > > + arm,trig-filters: > > > + allOf: > > > + - $ref: /schemas/types.yaml#/definitions/uint32-array > > > + minItems: 1 > > > + maxItems: 32 > > > + description: > > > + List of CTI trigger out signals that will be blocked from becoming > > > + active, unless filtering is disabled on the driver. > > > + > > > + arm,trig-conn-name: > > > + allOf: > > > + - $ref: /schemas/types.yaml#/definitions/string > > > + description: > > > + Defines a connection name that will be displayed, if the cpu or > > > + arm,cs-dev-assoc properties are not being used in this connection. > > > + Principle use for CTI that are connected to non-CoreSight devices, or > > > + external IO. > > > + > > > + anyOf: > > > + - required: > > > + - arm,trig-in-sigs > > > + - required: > > > + - arm,trig-out-sigs > > > + oneOf: > > > + - required: > > > + - arm,trig-conn-name > > > + - required: > > > + - cpu > > > + - required: > > > + - arm,cs-dev-assoc > > > + required: > > > + - reg > > > > You need 'reg' defined as a property too along with any constraints. > > > > OK - will do. > > > You also need #size-cells and #address-cells in the parent. And are they > > required? > > > > Size cells/ address cells can be defined and limited to appropriate values. > > However they are only required if the binding defines optional child > nodes per the patternProperties: '^trig-conns@([0-9]+)$': pattern. > I have not been able to find a form a .yaml that can encode this requirement. > if ( element matches "trig-conns") > then required (#size-cells, #address-cells.) I think there's not yet a way until something like this is accepted: https://github.com/json-schema-org/json-schema-spec/issues/117 You could express it if you knew there's always at least 'trig-conns@0' or some other unit-address. But if you don't know what unit-addresses you'll have, then you can't. > > What I do find is that if a trig-conns element has been defined, then > the binding will not compile correctly without #size-cells and > #address-cells. Right, dtc checks this already, so not too important that the schema be able to. Rob
