On Wed, Jan 23, 2019 at 06:29:09PM +0000, Mike Leach wrote:
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 above sentence "The ECT components are not part of the trace generation data path and are thus not part of the CoreSight graph described above." threw me off. Maybe that's a sign confirming that we should have a bindings/arm/coresight-cti.txt file. After all they are very different components
+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
That's a start.
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.
See what works best. Generating attributes on the fly is painful and clunky to manage. This is work in progress and we will likely have to iterate a few times over this.
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
-- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK