Re: [RFC PATCH v3 05/16] devicetree: bindings: Documentation for CTI bindings.

On Wed, Jun 05, 2019 at 08:03:02PM +0100, Mike Leach wrote:

Adds new .txt file describing the bindings required to define CTI in the device trees.

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

.../bindings/arm/coresight-ect-cti.txt | 203 ++++++++++++++++++

Yes, we need a new file.

.../devicetree/bindings/arm/coresight.txt | 7 + MAINTAINERS | 1 + 3 files changed, 211 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/coresight-ect-cti.txt

diff --git a/Documentation/devicetree/bindings/arm/coresight-ect-cti.txt b/Documentation/devicetree/bindings/arm/coresight-ect-cti.txt new file mode 100644 index 000000000000..ba95c0002ccc --- /dev/null +++ b/Documentation/devicetree/bindings/arm/coresight-ect-cti.txt @@ -0,0 +1,203 @@ +*CoreSight Embedded Cross Trigger Components

+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 +are not part of the trace generation data path and are thus not part of the +CoreSight graph described above.

What "CoreSight graph described above" are you referring to? Could that be from an earlier version where CTI bindings were part of 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. +Note that some hardware trigger signals can be connected to non-CoreSight +components (e.g. UART etc) depending on hardware implementation.

+CTIs are interconnect 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, other than when v8 core and ETM is present. The v8 +architecture then defines the required signal connections between core and CTI, +and ETM and CTI, if the ETM if present.

+Certain triggers between CoreSight devices and the CTI have specific types / +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.

+The minimum required binding for a CTI consist of the only the required

s/"of the only the"/"of the only"

+properties above.

Not sure about the word "above" - I can't find any properties above.

+e.g.

• /* sys cti 0 - connects to STM, ETF0 (core trace) TPIU and ETR */
• cti0: cti@20020000 {

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

• reg = <0x20020000 0x1000>;
  

• clocks = <&soc_smc50mhz>;
  

• clock-names = "apb_pclk";
  

• power-domains = <&scpi_devpd 0>;
  

One line too many.

• };

+This will result in the driver 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.

+Where information is immediately available for the component connections then +a series of trigger connection nodes can be defined (trig-conns).

+These connections explicitly define the input and output triggers between the +CTI and a connected component. Connections to an cpu use the standard cpu +property, connections to other CoreSight components use the arm,cs-dev-assoc +property.

+Where the signals are connected to a device that is not coresight device then

s/coresight/CoreSight

+no association is registered.

+cti@858000 {

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

•   reg = <0x858000 0x1000>;
  

•   clocks = <&rpmcc RPM_QDSS_CLK>;
  

•   clock-names = "apb_pclk";
  

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

•   };
  

+};

+Note that where input and output triggers are defined as above, then the driver +will limit the channel connection sysfs API to using only the defined signals.

+The arm,trig-filters property blocks output signals that could cause system +issues is set - such as the dbgreq signal into a CPU. The filtering is

s/is/if

+enabled by default, but can be disabled at runtime.

+Finally, a CTI that is an architecturally defined v8 CTI connected to a cpu +and optional ETM may be declared as:

+cti@859000 {

• compatible = "arm,coresight-cti", "arm,primecell";
• reg = <0x859000 0x1000>;
• clocks = <&rpmcc RPM_QDSS_CLK>;
• clock-names = "apb_pclk";
• arm,cti-v8-arch;
• cpu = <&CPU1>;
• arm,cs-dev-assoc = <&etm1>;

+};

+The arm,cti-v8-arch property declares this as a v8 CTI, the cpu property must +be present, and 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 debreq signal as described above.

s/debreq/dbgreq

+All the CTI devices are associated with a CTM. On many systems there will be a +single effective CTM (one CTM, or multiple CTMs all interconnected), but it is +possible that systems can have nets of CTIs+CTM that are not interconnected by

• a CTM. On these systems a CTM index is declared to associate CTI devices that
• are interconnected via the CTM.

The above two lines have one space too many at the beginning.

• e.g.
• arm,ctm-ctm-id=<2>

+CTI devices with the same CTM ID are considered connected by the CTM. If this +parameter is absent then all CTIs are considered interconnected by the same +CTM.

+*Summary of CTI required properties:

• • compatible : should be "arm,coresight-cti"; supplemented with

•      "arm,primecell" since this driver is using the AMBA bus
  

•  interface.
  

• • reg: physical base address and length of the register

•  set(s) of the component.
  

• • clocks: the clocks associated to this component.
• • clock-names: the name of the clocks referenced by the code.

•  Since we are using the AMBA framework, the name of the clock
  

•  providing the interconnect should be "apb_pclk", and some
  

•  coresight blocks also have an additional clock "atclk", which
  

s/coresight/CoreSight

•  clocks the core of that coresight component. The latter clock
  

s/coresight/CoreSight

•  is optional.
  

+*Summary of CTI optional properties:

• * trig-conns : defines a connection node between CTI and a component.
  

• Component may be a CPU, CoreSight device, any other hardware device
  

• or simple external IO lines.
  

• *arm,trig-in-sigs: List of CTI trigger in signals in use by a
  

• trig-conns node. Only valid as property of trig-conns node.
  

• *arm,trig-in-types: List of 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: List of CTI trigger out signals in use by a
  

• trig-conns node. Only valid as property of trig-conns node.
  

• *arm,trig-out-types: List of 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: List of CTI trigger out signals that will be
  

s/arm-trig-filters/arm,trig-filters

• blocked from becoming active, unless filtering is disabled on the
  

• driver. Only valid as property of trig-conns node.
  

• *arm,cti-v8-arch: Declares this CTI device as a v8 architecturally
  

• defined device. Use in CTI base node only, no additional trig-conns
  

• nodes permitted if this is declared.
  

• *cpu : defines a phandle reference to an associated CPU. Use in
  

s/"cpu :"/"cpu:" s/Use/Used

• trig-conns node, or in CTI base node when arm,cti-v8-arch present.
  

• *arm,cs-dev-assoc: 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.
  

• *arm,trig-conn-name: defines a connection name that will be displayed,
  

• if not overridden by the name of associated device from
  

• arm,cs-dev-assoc or the CPU. Only valid as property of trig-conns node.
  

• Principle use for CTI that are connected to non-coresight devices,
  

s/coresight/CoreSight

• or external IO.
  

• *arm,ctm-ctm-id: Defines the interconnecting CTM for this device.
  

• Use in CTI base node.
  

diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt index 8a88ddebc1a2..c00f2aae188a 100644 --- a/Documentation/devicetree/bindings/arm/coresight.txt +++ b/Documentation/devicetree/bindings/arm/coresight.txt @@ -45,6 +45,10 @@ its hardware characteristcs. - Coresight Address Translation Unit (CATU) "arm,coresight-catu", "arm,primecell";

• - Coresight Cross Trigger Interface (CTI):
  

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

• 	See coresight-ect-cti.txt for full CTI definitions.
  

• • reg: physical base address and length of the register set(s) of the component.

@@ -67,6 +71,9 @@ its hardware characteristcs.

• reg-names: the only acceptable values are "stm-base" and "stm-stimulus-base", each corresponding to the areas defined in "reg".

+* Required properties for Coresight Cross Trigger Interface (CTI)

•   See coresight-ect-cti.txt for full CTI definitions.
  

• Required properties for devices that don't show up on the AMBA bus, such as non-configurable replicators and non-configurable funnels:

diff --git a/MAINTAINERS b/MAINTAINERS index 5cfbea4ce575..4e5811b59e53 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1545,6 +1545,7 @@ F: Documentation/trace/coresight.txt F: Documentation/trace/coresight-cpu-debug.txt F: Documentation/devicetree/bindings/arm/coresight.txt F: Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt +F: Documentation/devicetree/bindings/arm/coresight-ect-cti.txt F: Documentation/ABI/testing/sysfs-bus-coresight-devices-* F: tools/perf/arch/arm/util/pmu.c F: tools/perf/arch/arm/util/auxtrace.c -- 2.20.1

---

CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight