[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DB7PR08MB3355B1A444324DBC5AF8003C86BB0@DB7PR08MB3355.eurprd08.prod.outlook.com>
Date: Wed, 27 Jan 2021 13:00:37 +0000
From: Al Grant <Al.Grant@....com>
To: Peter Zijlstra <peterz@...radead.org>,
Anshuman Khandual <Anshuman.Khandual@....com>
CC: "coresight@...ts.linaro.org" <coresight@...ts.linaro.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"lcherian@...vell.com" <lcherian@...vell.com>,
"mike.leach@...aro.org" <mike.leach@...aro.org>
Subject: RE: [PATCH V3 14/14] coresight: etm-perf: Add support for trace
buffer format
> > +/* CoreSight PMU AUX buffer formats */
> > +#define PERF_AUX_FLAG_CORESIGHT_FORMAT_CORESIGHT 0x0000 /*
> Default for backward compatibility */
> > +#define PERF_AUX_FLAG_CORESIGHT_FORMAT_RAW 0x0100 /*
> Raw format of the source */
>
> Would CORESIGHT_FORMAT_ETR / CORESIGHT_FORMAT_TRBE be better
> names?
Unformatted (raw) streams could be used any time you had a writer dedicated
to a single trace source. So in a situation where you had one ETR per CPU,
it would be appropriate to use an unformatted stream. A TRBE is always
dedicated to a single CPU, but potentially you (i.e. when designing the system)
can do this with any type of trace sink. So the raw/formatted distinction is
really about whether you are combining multiple streams in one buffer or not,
rather than the type of block that is writing into the buffer.
Al
Powered by blists - more mailing lists