From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753939AbcFGKZQ (ORCPT ); Tue, 7 Jun 2016 06:25:16 -0400 Received: from mga09.intel.com ([134.134.136.24]:27624 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751723AbcFGKZO (ORCPT ); Tue, 7 Jun 2016 06:25:14 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,432,1459839600"; d="scan'208";a="715161389" From: Alexander Shishkin To: Chunyan Zhang , rostedt@goodmis.org, mathieu.poirier@linaro.org, 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: Re: [RFC PATCH 1/4] STM Ftrace: Adding generic buffer interface driver In-Reply-To: <1464779939-24986-2-git-send-email-zhang.chunyan@linaro.org> References: <1464779939-24986-1-git-send-email-zhang.chunyan@linaro.org> <1464779939-24986-2-git-send-email-zhang.chunyan@linaro.org> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 07 Jun 2016 13:25:09 +0300 Message-ID: <87fuspqosa.fsf@ashishki-desk.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Chunyan Zhang writes: > This patch adds a driver that models itself as an stm_source and > who's sole purpose is to export an interface to the rest of the > kernel. Once the stm and stm_source have been linked via sysfs, > everything that is passed to the interface will endup in the STM > trace engine. STM core already provides this exact interface to the rest of the kernel. You need something that ftrace will call into to export its traces. > > Signed-off-by: Chunyan Zhang > --- > drivers/hwtracing/stm/Kconfig | 9 +++++++ > drivers/hwtracing/stm/Makefile | 2 ++ > drivers/hwtracing/stm/stm_ftrace.c | 54 ++++++++++++++++++++++++++++++++++++++ > 3 files changed, 65 insertions(+) > create mode 100644 drivers/hwtracing/stm/stm_ftrace.c > > diff --git a/drivers/hwtracing/stm/Kconfig b/drivers/hwtracing/stm/Kconfig > index 847a39b..a36633a 100644 > --- a/drivers/hwtracing/stm/Kconfig > +++ b/drivers/hwtracing/stm/Kconfig > @@ -39,4 +39,13 @@ config STM_SOURCE_HEARTBEAT > If you want to send heartbeat messages over STM devices, > say Y. > > +config STM_FTRACE > + tristate "Redirect/copy the output from kernel Ftrace to STM engine" > + help > + This option can be used to redirect or copy the output from kernel Ftrace > + to STM engine. Enabling this option will introduce a slight timing effect. This creates an impression that STM_FTRACE will somehow make events bypass the normal ftrace ring buffer. > + > + If you want to send kernel Ftrace messages over STM devices, > + say Y. > + > endif > diff --git a/drivers/hwtracing/stm/Makefile b/drivers/hwtracing/stm/Makefile > index a9ce3d4..5eef041 100644 > --- a/drivers/hwtracing/stm/Makefile > +++ b/drivers/hwtracing/stm/Makefile > @@ -9,3 +9,5 @@ obj-$(CONFIG_STM_SOURCE_HEARTBEAT) += stm_heartbeat.o > > stm_console-y := console.o > stm_heartbeat-y := heartbeat.o > + > +obj-$(CONFIG_STM_FTRACE) += stm_ftrace.o We don't have any other source files prefixed with "stm_" in drivers/hwtracing/stm, because the directory is already "stm". > diff --git a/drivers/hwtracing/stm/stm_ftrace.c b/drivers/hwtracing/stm/stm_ftrace.c > new file mode 100644 > index 0000000..0b4eb70 > --- /dev/null > +++ b/drivers/hwtracing/stm/stm_ftrace.c > @@ -0,0 +1,54 @@ > +/* > + * Simple kernel driver to link kernel Ftrace and an STM device > + * Copyright (c) 2016, Linaro Ltd. > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms and conditions of the GNU General Public License, > + * version 2, as published by the Free Software Foundation. > + * > + * This program is distributed in the hope it will be useful, but WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for > + * more details. > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +static struct stm_source_data stm_ftrace_data = { > + .name = "stm_ftrace", > + .nr_chans = 1, Unless you want to allocate one channel per cpu core, which might or might not be more efficient, but it would be nice to see at least a comment about it. > +}; > + > +/** > + * stm_ftrace_write() - write data to STM via 'stm_ftrace' source > + * @buf: buffer containing the data packet > + * @len: length of the data packet > + * @chan: offset above the start channel number allocated to 'stm_ftrace' > + */ > +void notrace stm_ftrace_write(const char *buf, unsigned int len, > + unsigned int chan) > +{ > + stm_source_write(&stm_ftrace_data, chan, buf, len); > +} > +EXPORT_SYMBOL_GPL(stm_ftrace_write); An extra wrapper around stm_source_write(). > + > +static int __init stm_ftrace_init(void) > +{ > + return stm_source_register_device(NULL, &stm_ftrace_data); > +} > + > +static void __exit stm_ftrace_exit(void) > +{ > + stm_source_unregister_device(&stm_ftrace_data); > +} So basically when ftrace is compiled in, it will pull in stm core through this. Regards, -- Alex