Hi Mathieu,Ack on the spelling issues - more detailed responses below. On Thu, 17 Jan 2019 at 20:36, Mathieu Poirier mathieu.poirier@linaro.org wrote:
On Wed, Jan 09, 2019 at 10:54:41PM +0000, Mike Leach wrote:
Adds CTI description to main coresight.txt file. Adds CTI bindings into device tree doc coresight file.
Signed-off-by: Mike Leach mike.leach@linaro.org
.../testing/sysfs-bus-coresight-devices-cti | 178 ++++++++++++++++++
This goes in a sparate patch.
will do.
.../devicetree/bindings/arm/coresight.txt | 173 +++++++++++++++++
This needs to be sent in a patch on its own since the DT binding maintainers need to ACK it before I can pick it up.
Documentation/trace/coresight.txt | 125 +++++++++++-
This would also be in a separate patch since it goes in the Documentation directory, something that is maintained by Jon Corbet. I will do a first pass on it now and may come back to it later. Please see below.
3 files changed, 475 insertions(+), 1 deletion(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-cti
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-cti b/Documentation/ABI/testing/sysfs-bus-coresight-devices-cti new file mode 100644 index 000000000000..82289de0d67f --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-cti @@ -0,0 +1,178 @@ +What: /sys/bus/coresight/devices/<memory_map>.cti/enable +Date: Jan 2019 +KernelVersion 5.x
Always put the kernel you are targeting. In this case it is 5.0.
OK
+Contact: ?
You, me or both of us - the choice is yours.
Wasn't sure on this. will update.
+Description: (RW) Enable/Disable the CTI hardware.
+What: /sys/bus/coresight/devices/<memory_map>.cti/ctmid +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (R) Display the associated CTM ID
+What: /sys/bus/coresight/devices/<memory_map>.cti/list_features +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (R) List the static hardware features of the CTI device.
Lists the connections to other devices, and the available input
and output triggers in these connections.
+What: /sys/bus/coresight/devices/<memory_map>.cti/regs/inout_sel +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (RW) Select the index for inen and outen registers.
+What: /sys/bus/coresight/devices/<memory_map>.cti/regs/inen +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (RW) Read or write the CTIINEN register selected by inout_sel.
+What: /sys/bus/coresight/devices/<memory_map>.cti/regs/outen +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (RW) Read or write the CTIOUTEN register selected by inout_sel.
+What: /sys/bus/coresight/devices/<memory_map>.cti/regs/gate +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (RW) Read or write CTIGATE register.
+What: /sys/bus/coresight/devices/<memory_map>.cti/regs/asicctl +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (RW) Read or write ASICCTL register.
+What: /sys/bus/coresight/devices/<memory_map>.cti/regs/intack +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (W) Write the INTACK register.
+What: /sys/bus/coresight/devices/<memory_map>.cti/regs/appset +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (RW) Set CTIAPPSET register to activate channel. Read back to
determine current value of register.
+What: /sys/bus/coresight/devices/<memory_map>.cti/regs/appclear +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (W) Write APPCLEAR register to deactivate channel.
+What: /sys/bus/coresight/devices/<memory_map>.cti/regs/apppulse +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (W) Write APPPULSE to pulse a channel active for one clock
cycle.
+What: /sys/bus/coresight/devices/<memory_map>.cti/regs/chinstatus +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (R) Read current status of channel inputs.
+What: /sys/bus/coresight/devices/<memory_map>.cti/regs/choutstatus +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (R) read current status of channel outputs.
+What: /sys/bus/coresight/devices/<memory_map>.cti/regs/triginstatus +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (R) read current status of input trigger signals
+What: /sys/bus/coresight/devices/<memory_map>.cti/regs/trigoutstatus +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (R) read current status of output trigger signals.
+What: /sys/bus/coresight/devices/<memory_map>.cti/channels/trigin_attach +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (W) Attach a CTI input trigger to a CTM channel.
+What: /sys/bus/coresight/devices/<memory_map>.cti/channels/trigin_detach +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (W) Detach a CTI input trigger from a CTM channel.
+What: /sys/bus/coresight/devices/<memory_map>.cti/channels/trigout_attach +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (W) Attach a CTI output trigger to a CTM channel.
+What: /sys/bus/coresight/devices/<memory_map>.cti/channels/trigout_detach +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (W) Detach a CTI output trigger from a CTM channel.
+What: /sys/bus/coresight/devices/<memory_map>.cti/channels/gate_enable +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (W) Enable CTIGATE for single channel or all channels.
+What: /sys/bus/coresight/devices/<memory_map>.cti/channels/gate_disable +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (W) Disable CTIGATE for single channel or all channels.
+What: /sys/bus/coresight/devices/<memory_map>.cti/channels/chan_set +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (W) Activate a single channel.
+What: /sys/bus/coresight/devices/<memory_map>.cti/channels/chan_clear +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (W) Deactivate a single channel.
+What: /sys/bus/coresight/devices/<memory_map>.cti/channels/chan_pulse +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (W) Pulse a single channel - activate for a single clock cycle.
+What: /sys/bus/coresight/devices/<memory_map>.cti/channels/trig_filter_enable +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (RW) Enable or disable trigger output signal filtering.
+What: /sys/bus/coresight/devices/<memory_map>.cti/channels/list_xtrigs +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (R) List the channel / trigger input and output programming.
+What: /sys/bus/coresight/devices/<memory_map>.cti/channels/list_chan_inuse +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (R) List channels currently in use and those with no attached
triggers.
+What: /sys/bus/coresight/devices/<memory_map>.cti/channels/reset_xtrigs +Date: Jan 2019 +KernelVersion 5.x +Contact: ? +Description: (W) Clear all channel / trigger programming. diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt index f8aff65ab921..f19a597aaccb 100644 --- a/Documentation/devicetree/bindings/arm/coresight.txt +++ b/Documentation/devicetree/bindings/arm/coresight.txt @@ -39,9 +39,13 @@ its hardware characteristcs.
- System Trace Macrocell: "arm,coresight-stm", "arm,primecell"; [1]
- Coresight Address Translation Unit (CATU) "arm,coresight-catu", "arm,primecell";
- Coresight CTI :
"arm,coresight-cti", "arm,primecell";
* reg: physical base address and length of the register set(s) of the component.
@@ -55,6 +59,7 @@ its hardware characteristcs. is optional.
* port or ports: see "Graph bindings for Coresight" below.
- Never used by CTI - see "ECT bindings for Coresight" below.
- Additional required properties for System Trace Macrocells (STM):
- reg: along with the physical base address and length of the register
@@ -94,6 +99,9 @@ its hardware characteristcs. * interrupts : Exactly one SPI may be listed for reporting the address error
+* Optional properties for CTI:
* See ECT bindings for CoreSight below.
Graph bindings for Coresight
@@ -315,3 +323,168 @@ Example:
[1]. There is currently two version of STM: STM32 and STM500. Both have the same HW interface and as such don't need an explicit binding name.
+ECT Bindings for CoreSight +--------------------------
+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.
I thought ECT was a term coined to represent both CTI and CTM.
Correct - the official name of the hardware technology is ECT - consisting of CTI and CTM components. The bindings primarily relate to CTI -> other device connections, but there is an entry to represent the interconnecting CTM, where more than one independent network of CTIs + CTMs is present.
+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.
+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 = <0 0x20020000 0 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
s/an cpu/a 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/not coresight/not a 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 {
reg = <0>;
arm,trig-in-sigs = <0 1 2 3>;
arm,trig-out-sigs = <4 5 6 7>;
arm,cs-dev-assoc = <&etm0>;
};
trig-conns@1 {
reg = <1>;
cpu = <&CPU0>;
arm,trig-out-sigs=<0 1 2 3>;
arm,trig-in-sigs=<4 5 6 7>;
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/issues is set/issues if set/
+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.
- 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 optional properties:
* trig-conns : defines a connection node between CTI and a component.
s/defines/Defines
Component may be a CPU, CoreSight device, any other hardware device
or simple external IO lines.
*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-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-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
s/defines/Defines
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
s/defines/Defines
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,
s/defines/Defines
And I think it would be worth giving an example of how the binding is used.
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.
*arm,ctm-ctm-id: Defines the interconnecting CTM for this device.
Use in CTI base node.
diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt index efbc832146e7..dc9708bea7f7 100644 --- a/Documentation/trace/coresight.txt +++ b/Documentation/trace/coresight.txt @@ -122,7 +122,7 @@ Device Tree Bindings
See Documentation/devicetree/bindings/arm/coresight.txt for details.
-As of this writing drivers for ITM, STMs and CTIs are not provided but are +As of this writing drivers for ITM, STMs are not provided but are expected to be added as the solution matures.
@@ -425,6 +425,129 @@ root@genericarmv8:~#
Details on how to use the generic STM API can be found here [2].
+CoreSight Embedded Cross Trigger (CTI & CTM). +---------------------------------------------
+The CoreSight Cross Trigger Interface (CTI) is a hardware device that takes +individual input and output hardware signals from devices and interconnects +them via the Cross Trigger Matrix (CTM) to other devices, in order to propogate
s/propogate/propagate/
+events between devices.
+e.g.
- 0000000 in_trigs :::::::
- 0 C 0----------->: :
- 0 P 0<-----------: :
- 0 U 0 out_trigs : : Channels *****
- 0000000 : CTI :<=========>*CTM*<====> (other CTI channel IO)
- ####### in_trigs : : (id 0-3) *****
- # ETM #----------->: :
- # #<-----------: :
- ####### out_trigs :::::::
+The CTI driver enables the programming of the CTI to attach triggers to +channels. When an input trigger becomes active, the attached channel will +become active. Any output trigger also attached to that channel will also +become active. The active channel is propogated to other CTIs via the CTMa
s/propogated/propagated/
+affecting output triggers there, unless filtered by the CTI channel gate.
+It is also possible to activate a channel using system software.
+The CTIs are registered by the system to be associated with CPUs and/or other +CoreSight devices on the trace data path. When these devices are enabled then +the attached CTIs will also be enabled. By default/on power up the CTIs have +no programmed trigger/channel attachments, so will not affect the system +until explicitly programmed.
+The hardware trigger connections between CTIs and devices is implementation +defined, unless the CPU/ETM combination is a v8 architecture, in which case +the connections have an architecturally defined standard layout.
+The hardware trigger signals can also be connected to non-CoreSight devices +(e.g. UART), or be propogated off chip as hardware IO lines.
s/propogated/propagated/
+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 CTI devices appear on the existing coresight bus alongside the other
s/coresight/CoreSight
+CoreSight devices.
+# ls /sys/bus/coresight/devices/858000.cti +channels ctmid enable list_features mgmt power regs subsystem uevent
+Key items are: +* enable: enables the CTI. +* ctmid : associated CTM - only relevant if system has multiple CTI+CTM clusters +that are not interconnected. +* list_features: displays available hardware defined connections and signals:-
+# cat /sys/bus/coresight/devices/859000.cti/list_features +CTI:859000.cti; Channels:4; Max Trigs:8 +CTM id = 0; Num Conns = 2
"Num Conns" can be misleading - wouldn't node be more appropriate since this is the therminology that is used in the bindings document.
+conn(0:cpu1) +Trig IN(3) [ 0 1 2 ] +Trig OUT(3) [ 0 1 2 ] +conn(1:85d000.etm) +Trig IN(4) [ 4 5 6 7 ] +Trig OUT(4) [ 4 5 6 7 ] +Trig OUT_FILTERED [ 0 ]
That will be a problem - the general rule for sysfs entries is to have one line of output for each.
OK - I can split that into more individual sysfs parameters. e.g. list_features -> Channels:4; Max Trigs:8 . CTM id = 0; Num Conns = 2 list_conns -> 0:cpu1 1:85d000.etm
For the trig in / out / filter info I could use a select con / list feature combo - a bit awkward but the only choice- unless generating sysfs attibutes on the fly is possible in which case each conection on the devicecan have its own set of trigin / out features to list.
Would this approach be acceptable?
+*channels: sub-dir containing the channel API - CTI main programming interface. +*regs: sub-dir giving access to the raw programmable CTI regs. +*mgmt: sub-dir for the standard CoreSight management registers.
+** Channels API : This provides an easy way to attach triggers to channels, +without needing the multiple register operations that are required if +manipluating the 'regs' sub-dir elements directly.
s/manipluating/manipulating/
+# ls /sys/bus/coresight/devices/859000.cti/channels/ +chan_clear gate_disable list_xtrigs trigin_attach trigout_detach +chan_pulse gate_enable reset_xtrigs trigin_detach +chan_set list_chan_inuse trig_filter_enable trigout_attach
+Most access to these elements take the form: +echo <chan> [<trigger>] > /<device_path>/<operation> +where the optional <trigger> is only needed for trigXX_at|detach operations.
+e.g. +echo 0 1 > /sys/bus/coresight/devices/859000.cti/channels/trigin_attach +attach trig_in(1) to channel(0). +echo 0 > /sys/bus/coresight/devices/859000.cti/channels/chan_set +activate channel(0)
+*gate_enable, gate_disable operations set the CTI gate to propogate
s/propogate/propagate/
+(enable) to other devices. These operation can take a channel number or 'all' +to operate on all channels. CTI gate is enabled by default at power up.
+*list_xtrigs will output the current channel / trig signal programming for the +CTI, alongside the channels enable through the CTI gate to propogate throughout
s/propogate/propagate/
+the CTM.
+# cat /sys/bus/coresight/devices/859000.cti/channels/list_xtrigs +CTI:859000.cti; Channels:4 +Chan 0: IN [ 1 ]; OUT [ 2 6 ]; +Chan 1: IN [ ]; OUT [ ]; +Chan 2: IN [ ]; OUT [ ]; +Chan 3: IN [ ]; OUT [ ]; +Gate Channels Enabled: [ 0 1 2 3 ]
This too will be a problem.
I would look to implement a similar method here as suggested above.
+*trig_filter_enable: defaults to enabled, disable to allow potentially +dangerous output signals to be set.
+*reset_xtrigs: clear all channel / trigger programming - reset device hardware +to default state.
+*list_chan_inuse: short list of channels that have any signals attached for +this CTI, and those that have none. +# cat /sys/bus/coresight/devices/859000.cti/channels/list_chan_inuse +Chan in use [ 0 ] +Chan free [ 1 2 3 ]
I will likely get back to this document later.
Thanks fo rthe review so far.
Mike
[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm [2]. Documentation/trace/stm.rst [3]. https://github.com/Linaro/perf-opencsd -- 2.19.1
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight