xref: /openbmc/linux/Documentation/trace/stm.rst (revision 217188d9)
1===================
2System Trace Module
3===================
4
5System Trace Module (STM) is a device described in MIPI STP specs as
6STP trace stream generator. STP (System Trace Protocol) is a trace
7protocol multiplexing data from multiple trace sources, each one of
8which is assigned a unique pair of master and channel. While some of
9these masters and channels are statically allocated to certain
10hardware trace sources, others are available to software. Software
11trace sources are usually free to pick for themselves any
12master/channel combination from this pool.
13
14On the receiving end of this STP stream (the decoder side), trace
15sources can only be identified by master/channel combination, so in
16order for the decoder to be able to make sense of the trace that
17involves multiple trace sources, it needs to be able to map those
18master/channel pairs to the trace sources that it understands.
19
20For instance, it is helpful to know that syslog messages come on
21master 7 channel 15, while arbitrary user applications can use masters
2248 to 63 and channels 0 to 127.
23
24To solve this mapping problem, stm class provides a policy management
25mechanism via configfs, that allows defining rules that map string
26identifiers to ranges of masters and channels. If these rules (policy)
27are consistent with what decoder expects, it will be able to properly
28process the trace data.
29
30This policy is a tree structure containing rules (policy_node) that
31have a name (string identifier) and a range of masters and channels
32associated with it, located in "stp-policy" subsystem directory in
33configfs. The topmost directory's name (the policy) is formatted as
34the STM device name to which this policy applies and and arbitrary
35string identifier separated by a stop. From the examle above, a rule
36may look like this::
37
38	$ ls /config/stp-policy/dummy_stm.my-policy/user
39	channels masters
40	$ cat /config/stp-policy/dummy_stm.my-policy/user/masters
41	48 63
42	$ cat /config/stp-policy/dummy_stm.my-policy/user/channels
43	0 127
44
45which means that the master allocation pool for this rule consists of
46masters 48 through 63 and channel allocation pool has channels 0
47through 127 in it. Now, any producer (trace source) identifying itself
48with "user" identification string will be allocated a master and
49channel from within these ranges.
50
51These rules can be nested, for example, one can define a rule "dummy"
52under "user" directory from the example above and this new rule will
53be used for trace sources with the id string of "user/dummy".
54
55Trace sources have to open the stm class device's node and write their
56trace data into its file descriptor. In order to identify themselves
57to the policy, they need to do a STP_POLICY_ID_SET ioctl on this file
58descriptor providing their id string. Otherwise, they will be
59automatically allocated a master/channel pair upon first write to this
60file descriptor according to the "default" rule of the policy, if such
61exists.
62
63Some STM devices may allow direct mapping of the channel mmio regions
64to userspace for zero-copy writing. One mappable page (in terms of
65mmu) will usually contain multiple channels' mmios, so the user will
66need to allocate that many channels to themselves (via the
67aforementioned ioctl() call) to be able to do this. That is, if your
68stm device's channel mmio region is 64 bytes and hardware page size is
694096 bytes, after a successful STP_POLICY_ID_SET ioctl() call with
70width==64, you should be able to mmap() one page on this file
71descriptor and obtain direct access to an mmio region for 64 channels.
72
73Examples of STM devices are Intel(R) Trace Hub [1] and Coresight STM
74[2].
75
76stm_source
77==========
78
79For kernel-based trace sources, there is "stm_source" device
80class. Devices of this class can be connected and disconnected to/from
81stm devices at runtime via a sysfs attribute called "stm_source_link"
82by writing the name of the desired stm device there, for example::
83
84	$ echo dummy_stm.0 > /sys/class/stm_source/console/stm_source_link
85
86For examples on how to use stm_source interface in the kernel, refer
87to stm_console, stm_heartbeat or stm_ftrace drivers.
88
89Each stm_source device will need to assume a master and a range of
90channels, depending on how many channels it requires. These are
91allocated for the device according to the policy configuration. If
92there's a node in the root of the policy directory that matches the
93stm_source device's name (for example, "console"), this node will be
94used to allocate master and channel numbers. If there's no such policy
95node, the stm core will pick the first contiguous chunk of channels
96within the first available master. Note that the node must exist
97before the stm_source device is connected to its stm device.
98
99stm_console
100===========
101
102One implementation of this interface also used in the example above is
103the "stm_console" driver, which basically provides a one-way console
104for kernel messages over an stm device.
105
106To configure the master/channel pair that will be assigned to this
107console in the STP stream, create a "console" policy entry (see the
108beginning of this text on how to do that). When initialized, it will
109consume one channel.
110
111stm_ftrace
112==========
113
114This is another "stm_source" device, once the stm_ftrace has been
115linked with an stm device, and if "function" tracer is enabled,
116function address and parent function address which Ftrace subsystem
117would store into ring buffer will be exported via the stm device at
118the same time.
119
120Currently only Ftrace "function" tracer is supported.
121
122* [1] https://software.intel.com/sites/default/files/managed/d3/3c/intel-th-developer-manual.pdf
123* [2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0444b/index.html
124