2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-16 09:13:55 +08:00

intel_th: Document software sinks

Add documentation for the software sinks API of the MSU driver and the
msu-sink module in particular.

Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Link: https://lore.kernel.org/r/20191114064201.43089-3-alexander.shishkin@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
Alexander Shishkin 2019-11-14 08:42:01 +02:00 committed by Greg Kroah-Hartman
parent 0a8f72fafb
commit 87ff16007c

View File

@ -44,7 +44,8 @@ Documentation/trace/stm.rst for more information on that.
MSU can be configured to collect trace data into a system memory
buffer, which can later on be read from its device nodes via read() or
mmap() interface.
mmap() interface and directed to a "software sink" driver that will
consume the data and/or relay it further.
On the whole, Intel(R) Trace Hub does not require any special
userspace software to function; everything can be configured, started
@ -122,3 +123,28 @@ In order to enable the host mode, set the 'host_mode' parameter of the
will show up on the intel_th bus. Also, trace configuration and
capture controlling attribute groups of the 'gth' device will not be
exposed. The 'sth' device will operate as usual.
Software Sinks
--------------
The Memory Storage Unit (MSU) driver provides an in-kernel API for
drivers to register themselves as software sinks for the trace data.
Such drivers can further export the data via other devices, such as
USB device controllers or network cards.
The API has two main parts::
- notifying the software sink that a particular window is full, and
"locking" that window, that is, making it unavailable for the trace
collection; when this happens, the MSU driver will automatically
switch to the next window in the buffer if it is unlocked, or stop
the trace capture if it's not;
- tracking the "locked" state of windows and providing a way for the
software sink driver to notify the MSU driver when a window is
unlocked and can be used again to collect trace data.
An example sink driver, msu-sink illustrates the implementation of a
software sink. Functionally, it simply unlocks windows as soon as they
are full, keeping the MSU running in a circular buffer mode. Unlike the
"multi" mode, it will fill out all the windows in the buffer as opposed
to just the first one. It can be enabled by writing "sink" to the "mode"
file (assuming msu-sink.ko is loaded).