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 ++++++++++++++++++ .../devicetree/bindings/arm/coresight.txt | 7 + 2 files changed, 210 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. + +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 +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>; + + }; + + +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 +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 +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. + +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. + + 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 + clocks the core of that coresight component. The latter clock + 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 + 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 + 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, + 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 f8aff65ab921..2013757b1f93 100644 --- a/Documentation/devicetree/bindings/arm/coresight.txt +++ b/Documentation/devicetree/bindings/arm/coresight.txt @@ -42,6 +42,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.
@@ -64,6 +68,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: