Hi Tor,
Running through the ETMv3 decode is making me think a bit more about the generic output packets.
For ETMv4, we output a OCSD_GEN_TRC_ELEM_PE_CONTEXT to indicate context info for the core, then a string of OCSD_GEN_TRC_ELEM_INSTR_RANGE for the instructions executed with the context.
This mirrors the way ETMv4 packet streams work.
ETMv3 and to a lesser extent PTM handles context differently, meaning we have to work harder to output the a OCSD_GEN_TRC_ELEM_PE_CONTEXT prior to the OCSD_GEN_TRC_ELEM_INSTR_RANGE packets.
It occurs to me that the context packet is only really relevant when processing the instruction ranges (and possibly for data tracing later on), so I was considering:-
1) Mandating that the context part of the generic packet structure is valid for the instruction range packet (it happens to be for the current decoder, but that is a consequence of how it is written rather than a deliberate rule). In future it can be mandated for data packets if required.
2) Dropping the OCSD_GEN_TRC_ELEM_PE_CONTEXT packets completely.
For the decoders this mandate is not onerous as they have to maintain the current context anyway to do the decode. Dropping a packet could simplify both decoder and library client operation.
How would this affect the current perf decode?
After the ETMv3 dev (or possibly at the end of it), I am going to expand the docs for the generic packets to set down these rules and dependencies.
Regards
Mike
----------------------------------------------------------------
Mike Leach +44 (0)1254 893911 (Direct)
Principal Engineer +44 (0)1254 893900 (Main)
Arm Blackburn Design Centre +44 (0)1254 893901 (Fax)
Belthorn House
Walker Rd mailto:mike.leach@arm.com
Guide
Blackburn
BB1 2QE
----------------------------------------------------------------
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi,
I'd like to get your thoughts on an appropriate low-level userspace API for STM.
The API I'm after would assume the ability to map a range of channels into
userspace as detailed in Documentation/trace/stm.txt:
"Some STM devices may allow direct mapping of the channel mmio region
to userspace for zero-copy writing..."
What that doesn't describe is what you do with the region once you've got it.
Which suggests a userspace API that can abstract over the way channels are
represented in the memory map, i.e. how bits of the address are used to
influence the data packets. Given a channel number (or a relative channel
number) and some data, it would generate a store to the right address,
or an lvalue at the right address. So you could write something like this:
STM_TRACE_DATA(p, TIMESTAMP, uint32, 123);
or perhaps
*STM_TRACE_CHANNEL(p, TIMESTAMP, uint32) = 123;
and this would become inline code that would be a single store that would
cause a D32 packet. The ARM and Intel implementations would differ
in how they calculated the address and perhaps on whether some features
were available. 64-bit writes would be unavailable on some ARM systems.
Userspace libraries that implemented higher-level messaging formats could
then sit on top of this lower-level API.
I don't think I've seen this in any of the patches that have come round but is
anyone working on anything like this?
Al
Mathieu/All,
I heard that there is a "tracing mini-summit" planned for ELC-E this
year. This is a "Linux plumbers" like conference. I believe the scope
is mostly about the SW trace frameworks (ftrace, LTP etc).
IMHO, this group should have some representation.
Likewise, since it is plumbers like we don't want to swamp them with a
bunch of people. I think 1 or 2 would be ideal.
[The RT Collaborative project is also planning a RT/Tracing mini-summit
as an add on to the main tracing summit.]
BTW: Despite what the ELC-E website says, the dates are not locked yet.
Any volunteers?
(Mathieu <-- poke poke)
Bill
----------------
William A. Mills
Chief Technologist, Open Solutions, SDO
Texas Instruments, Inc.
20450 Century Blvd
Germantown MD 20878
240-643-0836
Mike and Al,
When working with the TMC IP block and given that it was designed to
replace the ETB, how many people choose to set the DEVID::CONFIGTYPE
field to 0x0 (ETB)?
Do people mostly choose to go with an ETF nowadays?
Thanks,
Mathieu
