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
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Reply via email to