Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752282AbcKRDH6 (ORCPT ); Thu, 17 Nov 2016 22:07:58 -0500 Received: from mail-pf0-f176.google.com ([209.85.192.176]:33807 "EHLO mail-pf0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751527AbcKRDHz (ORCPT ); Thu, 17 Nov 2016 22:07:55 -0500 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, philippe.langlais@st.com, nicolas.guion@st.com, felipe.balbi@linux.intel.com, zhang.lyra@gmail.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [PATCH V8 0/3] Integration of function trace with System Trace IP blocks Date: Fri, 18 Nov 2016 11:07:31 +0800 Message-Id: <1479438454-28650-1-git-send-email-zhang.chunyan@linaro.org> X-Mailer: git-send-email 2.7.4 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5033 Lines: 112 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 store function tracing information produced by Ftrace and I'm taking the Function trace (trace type is TRACE_FN) as the example in this patchset, but other types of traces also can be supported. Logging information generated by the Ftrace subsystem to STM and gathered in the sink device 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 other architecture wishing to do the same. Comments 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 Changes from v7: * Addressed comments from Steven Rostedt: - Removed unnessecery code; - Shrinked the dependence of 'STM_SOURCE_FTRACE' from 'TRACING' to 'FUNCTION_TRACER'; - Changed the parameter type from char* to void*, that makes more sense. Changes from v6: * Rebased on v4.9-rc1; * Removed unused the declaration and header file including from trace.h which was added in patch 1 of this series; * Revised a bit the comments in trace.h . Changes from v5: * Addressed comments from Steven Rostedt: - Removed .commit() from trace_export; - Changed to directly call trace_process_export() instead of trace_export::commit(); - Used 'ring_buffer_event_length(event)' instead to get the trace size; - Removed trace_export pointer from trace_array structure. * Revised commit message a little to make the description more accurate. Changes from v4: * Addressed comments from Steven Rostedt: - Removed 'inline' annotations from the function which is called via function pointer; - Removed useless components from structure trace_export; - Added '__rcu' annotation to the RCU variables; - Used 'rcu_assign_pointer' to do every RCU assignment; - Added WARN_ON_ONCE() when the .write() is not assigned; - In order to reduce the overhead caused by adding this feature, this revision used an global array instead of a big "if statement" to get the size of trace entry according to the trace type. - In order to keep the current logic unchanged, made ftrace_exports() only being called if there's something have been added, i.e. if trace_export to stm_ftrace has been added in this patchset. Changes from v3: * Addressed comments from Steven Rostedt: - Added comments for the element 'name' and 'next' of trace_export; - Changed to use RCU functions instead of mutex in function callback; - Moved the check for name to register trace_export function; * Renamed 'trace_function_exports' to 'trace_exports' since its implementation is not only for function_trace; The similar changes on 'add_trace_export' and 'rm_trace_export'. Changes from v2: * Rebased on v4.8-rc1. * Added trace_export class, and make traces can be exported to not only ring buffer but also other area such as STM. * Made stm_ftrace as an trace_export. * More detailed changes are described in change log of each patch. Changes from v1: * 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 (3): tracing: add a possibility of exporting function trace to other places instead of ring buffer only stm class: ftrace: Add ftrace-export-over-stm driver 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 | 11 +++ drivers/hwtracing/stm/Makefile | 2 + drivers/hwtracing/stm/core.c | 7 +- drivers/hwtracing/stm/dummy_stm.c | 2 +- drivers/hwtracing/stm/ftrace.c | 87 +++++++++++++++++++ include/linux/stm.h | 4 +- include/linux/trace.h | 28 ++++++ kernel/trace/trace.c | 129 +++++++++++++++++++++++++++- 10 files changed, 271 insertions(+), 12 deletions(-) create mode 100644 drivers/hwtracing/stm/ftrace.c create mode 100644 include/linux/trace.h -- 2.7.4