Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756193AbbFPHGm (ORCPT ); Tue, 16 Jun 2015 03:06:42 -0400 Received: from mail-pa0-f51.google.com ([209.85.220.51]:34291 "EHLO mail-pa0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751535AbbFPHGl (ORCPT ); Tue, 16 Jun 2015 03:06:41 -0400 From: Chunyan Zhang To: rostedt@goodmis.org, mingo@redhat.com Cc: mathieu.poirier@linaro.org, serge.broslavsky@linaro.org, broonie@linaro.org, alexander.shishkin@linux.intel.com, zhang.lyra@gmail.com, linux-kernel@vger.kernel.org Subject: [RFC PATCH v2 0/3] Integration of trace events with System Trace IP blocks Date: Tue, 16 Jun 2015 15:06:10 +0800 Message-Id: <1434438373-32226-1-git-send-email-zhang.chunyan@linaro.org> X-Mailer: git-send-email 1.9.1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2692 Lines: 65 IP blocks allowing a variety of trace sources to log debugging information to a pre-defined area have been introduced on a couple of architecture [1][2]. These system trace blocks (also known as STM) typically follow the MIPI STPv2 protocol [3] and provide a system wide logging facility to any device, running a kernel or not, with access to the block's log entry port(s). Since each trace message has a timestamp is it possible to correlate events happening in the entire system rather than being confined to the logging facility of a single entity. This patch is using a very simple "stm_source" introduced in [2] to duplicate the output of the trace event subsystem to an STM, in this case coresight STM. That way logging information generated by the trace event subsystem and gathered in the coresight sink can be used in conjunction with trace data from other board components, also collected in the same trace sink. This example is using coresight but the same would apply to any architecture wishing to do the same. The goal of this RFC is to solicit comments on the method used to connect trace event logging with STMs (using the generic STM API) rather than function "stm_ftrace_write()" itself, which was provided for completeness of the proof of concept only. I'm eager to see your comments on this, and if you have some good ideas that can slow down the overhead, please let me know. Any questions are also welcome. Thanks, Chunyan [1]. https://lkml.org/lkml/2015/2/4/729 [2]. http://comments.gmane.org/gmane.linux.kernel/1914526 [3]. http://mipi.org/specifications/debug#STP Changes from RFC v1: - Marked module init/exit functions with __init/__exit key word according to the comments from Paul Bolle Chunyan Zhang (2): Trace log handler for logging into STM blocks Introduce trace log output function for STM Mathieu Poirier (1): STM trace event: Adding generic buffer interface driver drivers/stm/Kconfig | 11 +++++ drivers/stm/Makefile | 2 + drivers/stm/stm_trace_event.c | 46 +++++++++++++++++++ include/linux/ftrace_event.h | 15 +++++++ include/trace/ftrace.h | 47 +++++++++++++++++++ kernel/trace/Makefile | 1 + kernel/trace/trace_output_stm.c | 99 +++++++++++++++++++++++++++++++++++++++++ 7 files changed, 221 insertions(+) create mode 100644 drivers/stm/stm_trace_event.c create mode 100644 kernel/trace/trace_output_stm.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/