Hi All,

This proposal is a call for contribution for a STM driver and its possible usages in kernel tracing infrastructure. I'd like to know if another ARM SoC plan to use or already use STM or some similar hardware enabling the same kind of MIPI trace points. If yes, we can share our works.

What's STM?

Hardware overview: ------------------ This hardware collects and provides simple tracepoints, so a system processor (in our case the main ARM CPU, or some small CPUs and DSPs) can write some data, up to 8 bytes, into a register and out comes a log entry with a time stamp on one of 256 channels. Also hardware tracepoints are supported.

This module external interface is a pad on the chip which complies to the MIPI System Trace Protocol v1.0, and the actual trace output can be read by an electronic probe, not by software so it cannot be intercepted by the CPU and reach Linux userspace.

Bandwidth depends on number of lines & bus frequency (for example on ux500 SoC 4 lines at max 100MHz eg max 400Mbit/s shared between 7 cores). Transmit FIFO size: 256 samples up to 8 bytes.

Software overview: ------------------ - Put this platform driver in drivers/misc kernel tree - API: Configuration functions (trace output clock frequency, trace mode) Enable/disable STM trace functions Alloc/free STM trace channel functions Set of low level atomic trace functions for 1, 2, 4 or 8 bytes with & w/o time stamp Higher level lockless trace function (alloc a channel, output the trace buffer with arbitrary length then free the channel) Expose a debugfs interface for example to read/reset overflow status File IO output console like interface (open, close, write) Implement mmap to expose all STM trace channels memory access to userspace IOCTLs interface for configuration, enable/disable STM, alloc/free STM channels ... - Write atomicity and write order on STM trace channels is ensured by the fact we allocate one channel by execution thread (no concurrent access)

Possible usages: ---------------- - Provide multiple output consoles for traces

- Use it in standard kernel tracing infrastucture, possibilities: - Insert STM trace calls before trace ring buffer write - Substitute time stamping & trace ring buffer by STM - Implement the same functionality than the Ftrace function tracer without lock problem & very low overhead (in 8bytes + auto time stamp on 32bits arch we can have the function entry & its caller like Ftrace do). Remark: Problem is around lock to extract trace in right order when tracepoints buffer size > 8bytes (real time disturbance when tracing), a prototype must be done to find a clever lock system (use multiple channels)

- other ideas...

Many experiments must be done to validate its usage in kernel tracing infrastructure (performance, trace overflow, real time behavior...)

Regards, Philippe