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:
committed by
Greg Kroah-Hartman
parent
0a8f72fafb
commit
87ff16007c
@@ -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
|
|||||||
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).
|
||||||
|
|||||||
Reference in New Issue
Block a user