Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml

Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml

File Facts

System
Linux kernel
Corpus path
Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
Extension
.yaml
Size
11896 bytes
Lines
356
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: configuration, schema, or hardware description
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
# Copyright 2019 Linaro Ltd.
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/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.

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

allOf:
  - $ref: /schemas/arm/primecell.yaml#

# Need a custom select here or 'arm,primecell' will match on lots of nodes
select:
  properties:

Annotation

Implementation Notes