Commit 87ff1600 authored by Alexander Shishkin's avatar Alexander Shishkin Committed by Greg Kroah-Hartman

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: default avatarAlexander Shishkin <alexander.shishkin@linux.intel.com>
Link: https://lore.kernel.org/r/20191114064201.43089-3-alexander.shishkin@linux.intel.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
parent 0a8f72fa
...@@ -44,7 +44,8 @@ Documentation/trace/stm.rst for more information on that. ...@@ -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 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 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 On the whole, Intel(R) Trace Hub does not require any special
userspace software to function; everything can be configured, started 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 ...@@ -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 will show up on the intel_th bus. Also, trace configuration and
capture controlling attribute groups of the 'gth' device will not be capture controlling attribute groups of the 'gth' device will not be
exposed. The 'sth' device will operate as usual. 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).
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment