---------- Forwarded message ---------- From: Mathieu Poirier mathieu.poirier@linaro.org Date: 3 November 2015 at 21:27 Subject: Collection of metadata in a multi-session environment To: private-opencsd private-opencsd@linaro.org
As reported in my other email (Trace bundles for ETMv3/v4) moving to a multi-session scheme his forcing me to rethink how metadata is collected as one can no longer assume that what gets read from sysFS actually pertains to the session being reported.
When looking at the required registers (once again, please refer to Mike's document, section 4.3.1 to 4.3.3) a lot of them are RO:
ETMv3/PTM: ETMIDR ETMv4: TRCIDR[0, ..., 13], TRCAUTHSTATUS
Some are RW but can easily be made RO when using the CS framework from Perf:
ETMv3/PTM: ETMTRACEID ETMv4: TRCTRACEIDR
In fact I remember having this conversation with Mike in San Francisco and nobody would cry if we were to let the framework decide the traceIDs configured on the tracers.
Anything that is RO can still be retrieved using the current sysFS driven method since their values don't change. That leaves us with the other RW registers:
ETMv3/PTM: ETMCR, ETMCCR ETMv4: TRCCONFIGR
The question is, what information is needed from these registers in order to do trace decoding? Is there anything in there that is coming from the HW that can't be deduced otherwise? From what I understand we are talking about user configurable options that could be communicated to the trace decoding library using other means than conveying the whole registers. Using a bitmap is the first option that comes to mind, i.e, if cycle accurate tracing is configured, bit X is set.
With the above in mind I need you guys to help me identify the mandatory information in those tracer registers that is needed for trace decoding. Once again we can discuss this further in our meeting tomorrow.
Thanks, Mathieu