[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20121219210654.GA524@pratikp-linux.qualcomm.com>
Date: Wed, 19 Dec 2012 13:06:54 -0800
From: Pratik Patel <pratikp@...eaurora.org>
To: Will Deacon <will.deacon@....com>
Cc: "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linus.walleij@...aro.org" <linus.walleij@...aro.org>,
"linux@....linux.org.uk" <linux@....linux.org.uk>,
"magnus.p.persson@...ricsson.com" <magnus.p.persson@...ricsson.com>,
"arve@...roid.com" <arve@...roid.com>,
"jon-hunter@...com" <jon-hunter@...com>,
"david.rusling@...aro.org" <david.rusling@...aro.org>,
"dsaxena@...aro.org" <dsaxena@...aro.org>,
"john.stultz@...aro.org" <john.stultz@...aro.org>,
"d-deao@...com" <d-deao@...com>,
"christian.bejram@...ricsson.com" <christian.bejram@...ricsson.com>,
"devicetree-discuss@...ts.ozlabs.org"
<devicetree-discuss@...ts.ozlabs.org>,
linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: CoreSight framework and drivers
On Wed, Dec 19, 2012 at 11:23:14AM +0000, Will Deacon wrote:
> Hi Pratik,
>
> On Tue, Dec 18, 2012 at 07:19:17PM +0000, pratikp@...eaurora.org wrote:
> > This RFC is aimed at introducing CoreSight framework as well as
> > individual CoreSight trace component drivers adhering to ARM
> > CoreSight specification. Some prior discussion on this can be
> > referred at [1].
> >
> > There are 3 kinds of CoreSight trace components:
> >
> > * Sources: Responsible for producing trace data to provide
> > visibility for the associated entity.
> >
> > * Links: Transport components that carry trace data.
> >
> > * Sinks: Collectors for storing trace data or acting as conduits
> > for off-chip trace data collection.
> >
> > These components can be connected in various topologies to suite
> > a particular SoCs tracing needs.
> >
> > Framework is responsible for gathering and using the information
> > about the registered CoreSight components and their connections
> > to allow it to dynamically deduce the sequence of components
> > representing a connection from a CoreSight source to the
> > currently selected CoreSight sink. This helps the framework to
> > program the correct set of components to satisfy user request.
>
> From a million miles up, this looks like a sensible sort of design but I
> really think you need to talk to Jon Hunter (he's at least on CC) about
> this, especially where bindings are concerned. If we can get something that
> you both agree on, then we can include the CTI with the other coresight
> components and do a more in-depth review at that point.
>
Thanks for the feedback.
> Finally, how do you plan on exposing this data to the user? I think the only
> sane way is to have per-device file descriptors which act as pipes to the raw
> data but this means we need some readily available, open-source tooling (or
> at least public specifications of the trace formats).
>
The sink drivers (ETB, TMC), expose a device node per device that
is used to collect the raw data.
Eg:, we have:
/dev/coresight-etb
/dev/coresight-tmc-etf
/dev/coresight-tmc-etr
where reading /dev/coresight-tmc-etf only works when the ETF is
in circular buffer mode.
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists