mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-04 02:26:56 +07:00
docs: coresight: Update documentation for CoreSight to cover CTI
Add new document covering CTI / CTM usage in CoreSight. Add section in coresight.rst introducing CTI and CTM modules with link to new document. Signed-off-by: Mike Leach <mike.leach@linaro.org> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200320165303.13681-11-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
Mike Leach
Greg Kroah-Hartman
parent
3c5597e398
commit
82e0c782f8
222
Documentation/trace/coresight/coresight-ect.rst
Normal file
222
Documentation/trace/coresight/coresight-ect.rst
Normal file
@ -0,0 +1,222 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
=============================================
|
||||
CoreSight Embedded Cross Trigger (CTI & CTM).
|
||||
=============================================
|
||||
|
||||
:Author: Mike Leach <mike.leach@linaro.org>
|
||||
:Date: November 2019
|
||||
|
||||
Hardware Description
|
||||
--------------------
|
||||
|
||||
The CoreSight Cross Trigger Interface (CTI) is a hardware device that takes
|
||||
individual input and output hardware signals known as triggers to and from
|
||||
devices and interconnects them via the Cross Trigger Matrix (CTM) to other
|
||||
devices via numbered channels, in order to propagate events between devices.
|
||||
|
||||
e.g.::
|
||||
|
||||
0000000 in_trigs :::::::
|
||||
0 C 0----------->: : +======>(other CTI channel IO)
|
||||
0 P 0<-----------: : v
|
||||
0 U 0 out_trigs : : Channels ***** :::::::
|
||||
0000000 : CTI :<=========>*CTM*<====>: CTI :---+
|
||||
####### in_trigs : : (id 0-3) ***** ::::::: v
|
||||
# ETM #----------->: : ^ #######
|
||||
# #<-----------: : +---# ETR #
|
||||
####### 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 attached to that channel will also
|
||||
become active. The active channel is propagated to other CTIs via the CTM,
|
||||
activating connected output triggers there, unless filtered by the CTI
|
||||
channel gate.
|
||||
|
||||
It is also possible to activate a channel using system software directly
|
||||
programming registers in the CTI.
|
||||
|
||||
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 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 propagated off chip as hardware IO lines.
|
||||
|
||||
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 to each other. On these systems a CTM index is declared to associate
|
||||
CTI devices that are interconnected via a given CTM.
|
||||
|
||||
Sysfs files and directories
|
||||
---------------------------
|
||||
|
||||
The CTI devices appear on the existing CoreSight bus alongside the other
|
||||
CoreSight devices::
|
||||
|
||||
>$ ls /sys/bus/coresight/devices
|
||||
cti_cpu0 cti_cpu2 cti_sys0 etm0 etm2 funnel0 replicator0 tmc_etr0
|
||||
cti_cpu1 cti_cpu3 cti_sys1 etm1 etm3 funnel1 tmc_etf0 tpiu0
|
||||
|
||||
The ``cti_cpu<N>`` named CTIs are associated with a CPU, and any ETM used by
|
||||
that core. The ``cti_sys<N>`` CTIs are general system infrastructure CTIs that
|
||||
can be associated with other CoreSight devices, or other system hardware
|
||||
capable of generating or using trigger signals.::
|
||||
|
||||
>$ ls /sys/bus/coresight/devices/etm0/cti_cpu0
|
||||
channels ctmid enable nr_trigger_cons mgmt power powered regs
|
||||
subsystem triggers0 triggers1 uevent
|
||||
|
||||
*Key file items are:-*
|
||||
* ``enable``: enables/disables the CTI. Read to determine current state.
|
||||
If this shows as enabled (1), but ``powered`` shows unpowered (0), then
|
||||
the enable indicates a request to enabled when the device is powered.
|
||||
* ``ctmid`` : associated CTM - only relevant if system has multiple CTI+CTM
|
||||
clusters that are not interconnected.
|
||||
* ``nr_trigger_cons`` : total connections - triggers<N> directories.
|
||||
* ``powered`` : Read to determine if the CTI is currently powered.
|
||||
|
||||
*Sub-directories:-*
|
||||
* ``triggers<N>``: contains list of triggers for an individual connection.
|
||||
* ``channels``: Contains the channel API - CTI main programming interface.
|
||||
* ``regs``: Gives access to the raw programmable CTI regs.
|
||||
* ``mgmt``: the standard CoreSight management registers.
|
||||
|
||||
|
||||
triggers<N> directories
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Individual trigger connection information. This describes trigger signals for
|
||||
CoreSight and non-CoreSight connections.
|
||||
|
||||
Each triggers directory has a set of parameters describing the triggers for
|
||||
the connection.
|
||||
|
||||
* ``name`` : name of connection
|
||||
* ``in_signals`` : input trigger signal indexes used in this connection.
|
||||
* ``in_types`` : functional types for in signals.
|
||||
* ``out_signals`` : output trigger signals for this connection.
|
||||
* ``out_types`` : functional types for out signals.
|
||||
|
||||
e.g::
|
||||
|
||||
>$ ls ./cti_cpu0/triggers0/
|
||||
in_signals in_types name out_signals out_types
|
||||
>$ cat ./cti_cpu0/triggers0/name
|
||||
cpu0
|
||||
>$ cat ./cti_cpu0/triggers0/out_signals
|
||||
0-2
|
||||
>$ cat ./cti_cpu0/triggers0/out_types
|
||||
pe_edbgreq pe_dbgrestart pe_ctiirq
|
||||
>$ cat ./cti_cpu0/triggers0/in_signals
|
||||
0-1
|
||||
>$ cat ./cti_cpu0/triggers0/in_types
|
||||
pe_dbgtrigger pe_pmuirq
|
||||
|
||||
If a connection has zero signals in either the 'in' or 'out' triggers then
|
||||
those parameters will be omitted.
|
||||
|
||||
Channels API Directory
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This provides an easy way to attach triggers to channels, without needing
|
||||
the multiple register operations that are required if manipulating the
|
||||
'regs' sub-directory elements directly.
|
||||
|
||||
A number of files provide this API::
|
||||
|
||||
>$ ls ./cti_sys0/channels/
|
||||
chan_clear chan_inuse chan_xtrigs_out trigin_attach
|
||||
chan_free chan_pulse chan_xtrigs_reset trigin_detach
|
||||
chan_gate_disable chan_set chan_xtrigs_sel trigout_attach
|
||||
chan_gate_enable chan_xtrigs_in trig_filter_enable trigout_detach
|
||||
trigout_filtered
|
||||
|
||||
Most access to these elements take the form::
|
||||
|
||||
echo <chan> [<trigger>] > /<device_path>/<operation>
|
||||
|
||||
where the optional <trigger> is only needed for trigXX_attach | detach
|
||||
operations.
|
||||
|
||||
e.g.::
|
||||
|
||||
>$ echo 0 1 > ./cti_sys0/channels/trigout_attach
|
||||
>$ echo 0 > ./cti_sys0/channels/chan_set
|
||||
|
||||
Attaches trigout(1) to channel(0), then activates channel(0) generating a
|
||||
set state on cti_sys0.trigout(1)
|
||||
|
||||
|
||||
*API operations*
|
||||
|
||||
* ``trigin_attach, trigout_attach``: Attach a channel to a trigger signal.
|
||||
* ``trigin_detach, trigout_detach``: Detach a channel from a trigger signal.
|
||||
* ``chan_set``: Set the channel - the set state will be propagated around
|
||||
the CTM to other connected devices.
|
||||
* ``chan_clear``: Clear the channel.
|
||||
* ``chan_pulse``: Set the channel for a single CoreSight clock cycle.
|
||||
* ``chan_gate_enable``: Write operation sets the CTI gate to propagate
|
||||
(enable) the channel to other devices. This operation takes a channel
|
||||
number. CTI gate is enabled for all channels by default at power up. Read
|
||||
to list the currently enabled channels on the gate.
|
||||
* ``chan_gate_disable``: Write channel number to disable gate for that
|
||||
channel.
|
||||
* ``chan_inuse``: Show the current channels attached to any signal
|
||||
* ``chan_free``: Show channels with no attached signals.
|
||||
* ``chan_xtrigs_sel``: write a channel number to select a channel to view,
|
||||
read to show the selected channel number.
|
||||
* ``chan_xtrigs_in``: Read to show the input triggers attached to
|
||||
the selected view channel.
|
||||
* ``chan_xtrigs_out``:Read to show the output triggers attached to
|
||||
the selected view channel.
|
||||
* ``trig_filter_enable``: Defaults to enabled, disable to allow potentially
|
||||
dangerous output signals to be set.
|
||||
* ``trigout_filtered``: Trigger out signals that are prevented from being
|
||||
set if filtering ``trig_filter_enable`` is enabled. One use is to prevent
|
||||
accidental ``EDBGREQ`` signals stopping a core.
|
||||
* ``chan_xtrigs_reset``: Write 1 to clear all channel / trigger programming.
|
||||
Resets device hardware to default state.
|
||||
|
||||
|
||||
The example below attaches input trigger index 1 to channel 2, and output
|
||||
trigger index 6 to the same channel. It then examines the state of the
|
||||
channel / trigger connections using the appropriate sysfs attributes.
|
||||
|
||||
The settings mean that if either input trigger 1, or channel 2 go active then
|
||||
trigger out 6 will go active. We then enable the CTI, and use the software
|
||||
channel control to activate channel 2. We see the active channel on the
|
||||
``choutstatus`` register and the active signal on the ``trigoutstatus``
|
||||
register. Finally clearing the channel removes this.
|
||||
|
||||
e.g.::
|
||||
|
||||
.../cti_sys0/channels# echo 2 1 > trigin_attach
|
||||
.../cti_sys0/channels# echo 2 6 > trigout_attach
|
||||
.../cti_sys0/channels# cat chan_free
|
||||
0-1,3
|
||||
.../cti_sys0/channels# cat chan_inuse
|
||||
2
|
||||
.../cti_sys0/channels# echo 2 > chan_xtrigs_sel
|
||||
.../cti_sys0/channels# cat chan_xtrigs_trigin
|
||||
1
|
||||
.../cti_sys0/channels# cat chan_xtrigs_trigout
|
||||
6
|
||||
.../cti_sys0/# echo 1 > enable
|
||||
.../cti_sys0/channels# echo 2 > chan_set
|
||||
.../cti_sys0/channels# cat ../regs/choutstatus
|
||||
0x4
|
||||
.../cti_sys0/channels# cat ../regs/trigoutstatus
|
||||
0x40
|
||||
.../cti_sys0/channels# echo 2 > chan_clear
|
||||
.../cti_sys0/channels# cat ../regs/trigoutstatus
|
||||
0x0
|
||||
.../cti_sys0/channels# cat ../regs/choutstatus
|
||||
0x0
|
||||
@ -491,8 +491,21 @@ interface provided for that purpose by the generic STM API::
|
||||
|
||||
Details on how to use the generic STM API can be found here:- :doc:`../stm` [#second]_.
|
||||
|
||||
The CTI & CTM Modules
|
||||
---------------------
|
||||
|
||||
The CTI (Cross Trigger Interface) provides a set of trigger signals between
|
||||
individual CTIs and components, and can propagate these between all CTIs via
|
||||
channels on the CTM (Cross Trigger Matrix).
|
||||
|
||||
A separate documentation file is provided to explain the use of these devices.
|
||||
(:doc:`coresight-ect`) [#fourth]_.
|
||||
|
||||
|
||||
.. [#first] Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
|
||||
|
||||
.. [#second] Documentation/trace/stm.rst
|
||||
|
||||
.. [#third] https://github.com/Linaro/perf-opencsd
|
||||
|
||||
.. [#fourth] Documentation/trace/coresight/coresight-ect.rst
|
||||
|
||||
Loading…
Reference in New Issue
Block a user