Re: [PATCH v5 05/14] dt-bindings: arm: Adds CoreSight CTI hardware definitions.

Hi Mike,

On 19/11/2019 23:19, 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.

The documentation looks really nice and helpful. Some very minor nits below.

Signed-off-by: Mike Leach mike.leach@linaro.org

---

.../bindings/arm/coresight-cti.yaml | 303 ++++++++++++++++++ .../devicetree/bindings/arm/coresight.txt | 7 + MAINTAINERS | 2 + include/dt-bindings/arm/coresight-cti-dt.h | 37 +++ 4 files changed, 349 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..882c72f1c798 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/coresight-cti.yaml @@ -0,0 +1,303 @@ +# SPDX-License-Identifier: GPL-2.0 +# 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 CTM (which is not programmable). The ECT components

nit: CTM is not expanded anywhere here. For the sake of completeness, you may do that here.

i.e, s/"a start topology via the CTM"/"a start topology via the Cross Trigger Matrix (CTM)"/

• 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

nit: "programmable channels, usually 4, but..." ?

• 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, other than when v8 core and ETM is present.

nite: are implementation defined, *except when they are connected to an Arm v8 compatible CPU or an ETM* ?

• The v8 architecture defines the required signal connections between CPU core

nit: "The Arm v8"

• and CTI, and ETM and CTI, if the ETM if present.
• When only minimal information is available for the CTI trigger connections,
• then a minimal driver binding can be declare with no explicit trigger
• signals. This will result in the using the DEVID register to set the
• input and output triggers and channels in use. Any user / client
• application will require additional information on the connections
• between the CTI and other components for correct operation. This minimal
• binding may be used when using the Integration Control registers to
• discover connections between CTI and other CoreSight components,

How about "When the CTI trigger connection information is unavailable, the driver detects the number of triggers and channels from the DEVID register and makes them available. The Integration Control registers can be then used to discover the connections for this CTI device to other CoreSight components".

Since we recommend the use of the "Integration Control registers", which is not normally available unless you play around the code, it will be a good idea to metion, what the user needs to do to make the registers available. (One more reason to use the CONFIG symbol, makes that easier.)

• 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@linaro.org

+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:
• items:

•  - const: arm,coresight-cti
  

•  - const: arm,primecell
  

• reg:
• items:

•  - description: device programming registers
  

• arm,cti-v8-arch:

If possible, please could we make this :

"arm,cti-arm-v8-architected"

to be more meaning ful ?

• type: boolean
• description:

•  This CTI follows the v8 architecturally mandated layout for a CTI.
  

•  Bindings declaring this must declare a cpu, and optionally a single
  

•  arm,cs-dev-assoc may be present to define an attached ETM. No additional
  

•  trig-conns nodes are permitted. The driver will build a connection model
  

•  according to architectural requirements. This will include a filter on
  

•  the CPU dbgreq signal as described above.
  

• cpu:
• allOf:

•  - $ref: /schemas/types.yaml#/definitions/phandle
  

• description: Handle to cpu this device is associated with.
• arm,cti-ctm-id:
• allOf:

•  - $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:
• allOf:

•  - $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
  

•  arm,cti-v8-arch present. 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]+$':

I understand these bindings have been around for quite long and is too late to make any changes. So, feel free to ignore this suggestion below and I am perfectly fine with it.

--- Begin silly comments Or Skip to DONE ----

Could we make the property names a bit more obvious ? Since they are supposed to be written by other people (unlike our variable names), it always makes sense to have expanded, meaningful names:

s/trig_conns@/triggers@ ?

s/arm,trig-{in,out}-sigs/arm,cti-{in,out}-triggers s/arm,trig-{in,out}-types/arm,cti-{in,out}-trigger-types

"arm,trig-xxx" property name doesn't really imply that it is for cti. So, the above changes makes it explicit and more reader friendly.

• 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:
  

arm,cti-trigger-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:
  

arm,cti-trigger-name ?

--- DONE or End of silly comments ---

• # Implementation defined CTI - CPU + ETM connections explicitly defined..
• # Shows use of type constants from dt-bindings/arm/coresight-cti-dt.h
• • |
• #include <dt-bindings/arm/coresight-cti-dt.h>
• cti@858000 {

•  compatible = "arm,coresight-cti", "arm,primecell";
  

•  reg = <0x858000 0x1000>;
  

•  clocks = <&soc_smc50mhz>;
  

•  clock-names = "apb_pclk";
  

•  arm,cti-ctm-id = <1>;
  

•  trig-conns@0 {
  

•        arm,trig-in-sigs = <4 5 6 7>;
  

•        arm,trig-in-types = <ETM_EXTOUT
  

•                             ETM_EXTOUT
  

•                             ETM_EXTOUT
  

•                             ETM_EXTOUT>;
  

•        arm,trig-out-sigs = <4 5 6 7>;
  

•        arm,trig-out-types = <ETM_EXTIN
  

•                              ETM_EXTIN
  

•                              ETM_EXTIN
  

•                              ETM_EXTIN>;
  

•        arm,cs-dev-assoc = <&etm0>;
  

•  };
  

•  trig-conns@1 {
  

•        cpu = <&CPU0>;
  

•        arm,trig-in-sigs = <0 1>;
  

•        arm,trig-in-types = <PE_DBGTRIGGER
  

•                             PE_PMUIRQ>;
  

•        arm,trig-out-sigs=<0 1 2 >;
  

•        arm,trig-out-types = <PE_EDBGREQ
  

•                              PE_DBGRESTART
  

•                              PE_CTIIRQ>;
  

•        arm,trig-filters = <0>;
  

•  };
  

• };
• # Implementation defined CTI - none CoreSight component connections.

nit: s/none/non ?

Rest looks fine to me.

Suzuki