>
>4. Kernel API
>
>TI does not support a Kernel API (yet). I can see that the Alloc/Free
>and File IO type functions are useful and should be standard.
>
>Not sure what you mean by "lockless" trace functions?
>Not protected against concurrent access, it's the responsibility to the
>caller.
>
>It looks like your "low level atomic trace functions for 1, 2, 4 or 8
>bytes" is similar to TI's binary library functions (not supported by the
>TI STM Driver). This is what we use the OST header for, allowing our
>tool chain to differentiate between different message formats, rather
>than just assuming the data is a simple stream of bytes.
>I'm not ready to add an OST header to each trace messages to
>particularly for kernel function traces (ftrace has short messages 8
>bytes size with high throughput), I rather to dedicate a specific
>channel for this, OST header has to be optional.
>
>5. Debugfs APIs.
>
>TI used a different approach. The tool-chain on the host provides all
>the transport setup through JTAG, so our driver does not support setting
>up the actual STM data export (number of pins and clock rate). In our
>case device transport parameters must match the host receiver's
>collection setup.
>
>With your approach the user can change the clock rate and export pin
>width effectively at any time. Our tools actually go through a
>calibration process during initialization so any changes to the device's
>transport setup (clock rate, number of pins data exported on) would
>cause the TI tool chain a lot of grief.
>
>There are some parameters we know we need to add (like master enables).
>This are currently also handled by the host tools. TI's STM module
>allows up to 4 SW masters to be enabled (with id masks that can be used
>to enable multiple masters from the same group) and 4 HW masters that
>can be enabled at the same time as the SW masters. If the user tries to
>enable more than the HW allows do you have a mechanism to flag an error?
>We can't face the same problem with STE STM, our hardware support 6 SW
>masters & 2 HW masters without restriction, all could be enabled at same
>time (managed by a bit field register)
>
>I don't have a lot of experience with debugfs but I am assuming it's
>primarily used for allowing scripts to configure a driver (like in your
>example) or extract information.
>It's the current way to configure kernel tracing infrastructure (from
>console, through scripts or user apps), kernel users are familiar with
>this interface.
>
>We may want to define a standard set of debugfs options whose
>implementation is vendor specific. But that raises some questions:
>
>- How do we deal with options that don't make sense for a specific
>vendor?
> Maybe just doing nothing is acceptable or do we want to provide a
> discovery mechanism?
>Do nothing may be sufficient, we can add STM IP specific string
>descriptor too, something like "vendor id+STM IP id+STP version"
>- Would user scripts then also be vendor specific?
> We should probably make an effort to avoid this. A discovery mechanism
>may allow user mode scripts to be generic.
>Yes, but STM configuration scripts are device specific, to see.
>
>6. Mapped Channels
>
>I believe the TI hw transport channel mapping is compatible. In the TI
>case a channel is mapped into two spaces, the first half is for non-
>timestamp transfers and the second half is for time-stamped transfers.
>When we write a message (from a user mode write call for example) we
>simply write all the data except the last element through the non-
>timestamp port, and then the last element is written to the time-stamped
>port. So I think we could be compatible here.
>I think so, we have similar channel memory mapping but, one STM channel
>is accessed through this C union of 2 consecutive 64bits word (first for
>non-timestamp, 2nd with timestamp)
>/* One single channel mapping */
>struct stm_channel {
> union {
> __u8 no_stamp8;
> __u16 no_stamp16;
> __u32 no_stamp32;
> __u64 no_stamp64;
> };
> union {
> __u8 stamp8;
> __u16 stamp16;
> __u32 stamp32;
> __u64 stamp64;
> };
>};
>
>
>With that said I am not sure about exposing all channels to a user mode
>library. You are relying on the library to use the convention of getting
>a free channel from the driver to make sure there are no conflicts. If
>the channel assignment is made when you open the device, you could
>conceivably map just the address space needed for the single channel,
>thus eliminating the need to get a free channel from the driver. In the
>TI case a single channel's transport mapping is 4K bytes, which matches
>the typical PAGE_SIZE. I realize not all hw implementations will match
>up with the PAGE_SIZE, which may be why you simply map all the channels
>back to user space.
>It's our case, the 256 channels is mapped in the same 4K memory page.
>
>Since free channels can become busy rapidly, maybe a better convention
>would be to simply use another device node if the user wants the library
>STM data to be transmitted on a different STM channel than the current
>process. This may be a case where providing a mechanism (see meta data
>discussion below) to allow channels to be named for the toolchain may be
>a good idea (provide task name and process id).
>In our current implementation, a new open on the same "/dev/stm" device
>allocate a new channel at first write.
>
>7. 8-byte Writes
>
>TI does not support 64-bit writes with our STM 1.0 module. We may need
>an IOCTL to get the largest transfer supported for the mmap case. For
>all other cases this should just be hidden in the device dependent code.
>I think so
>
>8. Kernel Internal Usage
>
>I like the idea of having dedicated support in the driver for common
>kernel logging. Any ideas on how you would support kernel STM channel
>assignments without hard-coding?
>But configurable through kernel configuration, the other way is to
>dedicate a specific channel for this signalization like your channel
>255, not so easy to define.
>
>We may need a mechanism to communicate the definition of each hard-coded
>channel to our tools.
>to see
>
>
>The following are TI specific:
>
>9. Data protection
>
>In SMP systems if the processor is switched a new master is generated
>(in some TI devices). So we protect the data with a mutex to guarantee a
>complete message is generated by the same master.
>OK, it's not our case.
>
>10. Meta Data
>
>Our user mode HW libraries use meta data to transport data needed to
>process the HW profiling STM messages. Items like processor speed,
>sampling rate, processing options, ... (just a predefined byte buffer
>our tool-chain understands). The meta data is currently broadcasted on a
>dedicated channel (255), which conflicts with your hard-coded channel
>for logging printk output. So we will need to resolve hard-coded
>conflicts.
>Easy to fix, we can reserve dedicated channels at driver init and change
>our hard-coded affectation.
>
>We need the driver to support registration and transport of the meta
>data on demand from the library (when the HW master is disabled, in case
>the collection buffer is small and circular).
>
>I am thinking an IOCTL could be used to register meta data and then the
>data simply broadcast on a STM channel (will need to figure out which
>one) when the HW master is enabled and disabled.
>We don't face the same problematic
>
>Meta data transmission is problematic for circular buffers (like ETB's)
>thus the reason for also sending meta data when a hw master is disabled.
>SW masters are not typically disabled, and our HW does not provide a
>transmission byte count (remember there are HW messages also being
>generated in the TI case). So there is no way from a driver we can tell
>when the recoding buffer will wrap even if the user told us the buffer
>size. I am thinking the best solution would be to force the user to
>gracefully disable the channel to get any sw channel meta data provided
>by the driver.
>I think so, if I have well understood
>
>TI supports three cases of data capture:
>- DTC/Host collection (stop on buffer full)
>- DTC/Host collection (circular buffer)
>- ETB/on-chip collection (circular buffer)
>We don't support ETB/on-chip collection, We use external probe or
>Lauterbach combiprobe for
>trace data collection (I think it's circular buffer)
>
>
>Of if the user is at a point in their code where they know thery will
>stop recoding on the hOst or ETB, we provide an IOCTL that simply
>disables all channels.
>
>In the ETB case we may want to simply disable any open STM channels when
>the user decides to stop recording as a fail safe mechanism.
>
>Note: Periodic transmission of meta data into a small circular buffer
>will not work well. In cases where the data is sparse the buffer will
>simply be filled with meta data rather than useful data.
>
>
>11. OST Headers
>
>Adding an OST header to each message is a requirement for compatibility
>with TI's toolchain. There are a couple of ways to approach:
>
>Completely hidden from the user - The device specific code will know if
>the header is necessary. On a write, prior to the copy from user space,
>the device independent code would have to make a call to get a properly
>sized memory buffer from the device dependent code that would include
>the header.
>
>User enabled - Provide an IOCTL that allows the user to put the driver
>in a tool-chain specific mode (like add OST headers).
>I agree, see my previous remark on OST headers
>
>
>Regards,
>Doug Deao
>
>I attached my last STM patches which introduce trace framework.
>
>Best Regards,
>Philippe Langlais
>
>
>________________________________________
>From: Philippe Langlais [mailto:
philippe.langlais@linaro.org]
>Sent: Wednesday, May 04, 2011 3:08 AM
>To: Deao, Douglas
>Cc: Linus Walleij
>Subject: Re: STM at UDS-Budapest
>
>Hi Doug,
>
>On STE ux500 platforms we have the same STM module (follow MIDP STP
>1.0), I have already posted our current
>implementation to the LKML and Linaro ML, it's very similar to your
>proposal.
>I can't be present to the Linaro summit but Linus Walleij can replace me
>for this topic, he proposes to write a common
>trace framework to receive STM drivers.
>Attached all our current proposal and work around STM.
>
>Regards
>Philippe Langlais
>ST-Ericsson
>On 3 May 2011 00:42, Deao, Douglas <
d-deao@ti.com> wrote:
>I am hosting an introductory session on System Trace at the summit. TI's
>System Trace Module (STM) provides a common protocol for instrumentation
>messages across multiple cores and system level hardware profiling in
>complex SoCs. Attached is a whitepaper for background reading.
>
>Looking forward to meeting you at the summit.
>
>Regards,
>Doug Deao
>Texas Instruments
>
>
>_______________________________________________
>linaro-dev mailing list
>
linaro-dev@lists.linaro.org
>
http://lists.linaro.org/mailman/listinfo/linaro-dev