Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752523AbbFEFhE (ORCPT ); Fri, 5 Jun 2015 01:37:04 -0400 Received: from mail-wg0-f48.google.com ([74.125.82.48]:36105 "EHLO mail-wg0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750957AbbFEFhB (ORCPT ); Fri, 5 Jun 2015 01:37:01 -0400 MIME-Version: 1.0 In-Reply-To: References: <1433476110-11524-1-git-send-email-zhang.chunyan@linaro.org> Date: Fri, 5 Jun 2015 13:37:00 +0800 Message-ID: Subject: [RFC PATCH 0/3] Integration of trace events with System Trace IP blocks From: Chunyan Zhang To: Steven Rostedt , mingo@redhat.com Cc: Mathieu Poirier , Kaixu Xia , Serge Broslavsky , Mark Brown , alexander.shishkin@linux.intel.com, "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2521 Lines: 59 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. Regards, 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 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/