From: Chunyan Zhang <zhang.chunyan@linaro.org> To: Felipe Balbi <felipe.balbi@linux.intel.com> Cc: Steven Rostedt <rostedt@goodmis.org>, Mathieu Poirier <mathieu.poirier@linaro.org>, Alexander Shishkin <alexander.shishkin@linux.intel.com>, mingo@redhat.com, Arnd Bergmann <arnd@arndb.de>, Mike Leach <mike.leach@arm.com>, Tor Jeremiassen <tor@ti.com>, philippe.langlais@st.com, Nicolas GUION <nicolas.guion@st.com>, Lyra Zhang <zhang.lyra@gmail.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH V6 0/3] Integration of function trace with System Trace IP blocks Date: Thu, 8 Sep 2016 21:09:27 +0800 [thread overview] Message-ID: <CAG2=9p9d5qH9Ty3Lwh5v4z4uy078XKyw4ooJG5yXkZfFdaoOgQ@mail.gmail.com> (raw) In-Reply-To: <87inu6h9xz.fsf@linux.intel.com> Hi Balbi, On 8 September 2016 at 20:07, Felipe Balbi <felipe.balbi@linux.intel.com> wrote: > > Hi, > > Chunyan Zhang <zhang.chunyan@linaro.org> writes: >> 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. > > showing up late to the bandwagon, but this is very good. I've been > toying with the idea of exporting ftrace via USB and this will help > quite a bit. Thanks :-) Very happy this work may be helpful for you. > > I'll add to my TODO a look at this series. Great work. Yes, please help review, comments are very welcome. There's still some other work related this need to be done, this patch-set is the first step. I will keep you posted with any update. Thanks, Chunyan > > -- > balbi
WARNING: multiple messages have this Message-ID (diff)
From: zhang.chunyan@linaro.org (Chunyan Zhang) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH V6 0/3] Integration of function trace with System Trace IP blocks Date: Thu, 8 Sep 2016 21:09:27 +0800 [thread overview] Message-ID: <CAG2=9p9d5qH9Ty3Lwh5v4z4uy078XKyw4ooJG5yXkZfFdaoOgQ@mail.gmail.com> (raw) In-Reply-To: <87inu6h9xz.fsf@linux.intel.com> Hi Balbi, On 8 September 2016 at 20:07, Felipe Balbi <felipe.balbi@linux.intel.com> wrote: > > Hi, > > Chunyan Zhang <zhang.chunyan@linaro.org> writes: >> 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. > > showing up late to the bandwagon, but this is very good. I've been > toying with the idea of exporting ftrace via USB and this will help > quite a bit. Thanks :-) Very happy this work may be helpful for you. > > I'll add to my TODO a look at this series. Great work. Yes, please help review, comments are very welcome. There's still some other work related this need to be done, this patch-set is the first step. I will keep you posted with any update. Thanks, Chunyan > > -- > balbi
next prev parent reply other threads:[~2016-09-08 13:09 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-09-08 3:03 [PATCH V6 0/3] Integration of function trace with System Trace IP blocks Chunyan Zhang 2016-09-08 3:03 ` Chunyan Zhang 2016-09-08 3:03 ` [PATCH V6 1/3] tracing: add a possibility of exporting function trace to other places instead of ring buffer only Chunyan Zhang 2016-09-08 3:03 ` Chunyan Zhang 2016-09-08 3:03 ` [PATCH V6 2/3] stm class: ftrace: Add ftrace-export-over-stm driver Chunyan Zhang 2016-09-08 3:03 ` Chunyan Zhang 2016-09-08 3:03 ` [PATCH V6 3/3] stm: Mark the functions of writing buffer with notrace Chunyan Zhang 2016-09-08 3:03 ` Chunyan Zhang 2016-09-08 12:07 ` [PATCH V6 0/3] Integration of function trace with System Trace IP blocks Felipe Balbi 2016-09-08 12:07 ` Felipe Balbi 2016-09-08 13:09 ` Chunyan Zhang [this message] 2016-09-08 13:09 ` Chunyan Zhang
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAG2=9p9d5qH9Ty3Lwh5v4z4uy078XKyw4ooJG5yXkZfFdaoOgQ@mail.gmail.com' \ --to=zhang.chunyan@linaro.org \ --cc=alexander.shishkin@linux.intel.com \ --cc=arnd@arndb.de \ --cc=felipe.balbi@linux.intel.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mathieu.poirier@linaro.org \ --cc=mike.leach@arm.com \ --cc=mingo@redhat.com \ --cc=nicolas.guion@st.com \ --cc=philippe.langlais@st.com \ --cc=rostedt@goodmis.org \ --cc=tor@ti.com \ --cc=zhang.lyra@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.