Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756792AbbGGKML (ORCPT ); Tue, 7 Jul 2015 06:12:11 -0400 Received: from mail-pa0-f48.google.com ([209.85.220.48]:32797 "EHLO mail-pa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752568AbbGGKMD (ORCPT ); Tue, 7 Jul 2015 06:12:03 -0400 From: Chunyan Zhang To: rostedt@goodmis.org, mingo@redhat.com Cc: mathieu.poirier@linaro.org, serge.broslavsky@linaro.org, broonie@kernel.org, alexander.shishkin@linux.intel.com, zhang.lyra@gmail.com, linux-kernel@vger.kernel.org Subject: [RFC PATCH v3 0/4] Integration of trace events with System Trace IP blocks Date: Tue, 7 Jul 2015 18:10:39 +0800 Message-Id: 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: 3063 Lines: 74 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 v2: - Revised some types and variable's name according to the code of v4.2-rc1 - Sorted this patch-set based on the v4.2-rc1 - Splited the patch 2/3 of my last patch-set to make code can be compiled after each patch is applied in order. Changes from RFC v1: - Marked module init/exit functions with __init/__exit key word according to the comments from Paul Bolle Chunyan Zhang (3): trace: Add an entry for printing trace log to STM trace: Introduce trace log output function for STM trace: Trace log handler for logging into STM blocks 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/trace_events.h | 16 +++++++ include/trace/perf.h | 3 ++ include/trace/trace_events.h | 44 ++++++++++++++++++ kernel/trace/Makefile | 1 + kernel/trace/trace_output_stm.c | 99 +++++++++++++++++++++++++++++++++++++++++ 8 files changed, 222 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/