From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752484AbcFVCr1 (ORCPT ); Tue, 21 Jun 2016 22:47:27 -0400 Received: from mail-pa0-f54.google.com ([209.85.220.54]:36616 "EHLO mail-pa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752376AbcFVCr0 (ORCPT ); Tue, 21 Jun 2016 22:47:26 -0400 From: Chunyan Zhang To: rostedt@goodmis.org, mathieu.poirier@linaro.org, alexander.shishkin@linux.intel.com, mingo@redhat.com Cc: mike.leach@arm.com, tor@ti.com, maxime.coquelin@st.com, philippe.langlais@st.com, nicolas.guion@st.com, zhang.lyra@gmail.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [PATCH V2 0/4] Integration of function trace with System Trace IP blocks Date: Wed, 22 Jun 2016 10:46:49 +0800 Message-Id: <1466563613-31578-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 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, it is possible to correlate events happening in the entire system rather than being confined to the logging facility of a single entity. This patchset is trying to use STM IP blocks to collect some function tracing information produced by Ftrace. Since writing STM is relatively time-consuming, my thought is that export as much useful information as possible while using a limited bytes, in this patchset only function pointers were copied to STM. That way logging information generated by the function trace 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 ARM coresight STM but the same would apply to any architecture wishing to do the same. Comments and advice would be greatly appreciated. Thanks, Chunyan [1]. https://lwn.net/Articles/674746/ [2]. http://lxr.free-electrons.com/source/drivers/hwtracing/intel_th/ [3]. http://mipi.org/specifications/debug#STP [4]. http://lxr.free-electrons.com/source/include/linux/stm.h Changes v2: * Addressed comments from Alexander Shishkin: - Modified some ambiguous change logs. - Decoupled stm_ftrace and trace_output interface to STM. - Changed the file name from stm_ftrace.c to stm/ftrace.c. - Implemented link/unlink hooks for stm_ftrace. * Removed useless header file include from stm/ftrace.c * Added Acked-by from Steven Rostedt on 4/4. Chunyan Zhang (4): trace: Introduce an output interface from ftrace to STM STM Ftrace: Adding generic buffer interface driver trace: duplicate function pointer to STM stm: Mark the functions of writing buffer with notrace drivers/hwtracing/coresight/coresight-stm.c | 2 +- drivers/hwtracing/intel_th/sth.c | 11 +++-- drivers/hwtracing/stm/Kconfig | 10 ++++ drivers/hwtracing/stm/Makefile | 2 + drivers/hwtracing/stm/core.c | 7 +-- drivers/hwtracing/stm/dummy_stm.c | 2 +- drivers/hwtracing/stm/ftrace.c | 77 +++++++++++++++++++++++++++++ include/linux/stm.h | 11 ++++- include/linux/trace_output_stm.h | 17 +++++++ kernel/trace/Makefile | 1 + kernel/trace/trace.c | 5 +- kernel/trace/trace_output_stm.c | 41 +++++++++++++++ 12 files changed, 174 insertions(+), 12 deletions(-) create mode 100644 drivers/hwtracing/stm/ftrace.c create mode 100644 include/linux/trace_output_stm.h create mode 100644 kernel/trace/trace_output_stm.c -- 1.9.1