On 27 May 2011 10:45, Arnd Bergmann <a...@arndb.de> wrote: > On Thursday 26 May 2011, Philippe Langlais wrote: > > > > I initiate the work to build a hardware trace framework in the kernel, > I'm > > not started the study to > > have a common userspace API for STM, thanks to this email we can start > such > > a work, but > > it may be long (next week I'm in vacation till June 7th). > > I missed the initial parts of the conversation, but I think that regarding > the user interface, the most important issue by far is integration into > the perf events infrastructure. There is no room for having yet another > API to get at tracing and performance data. > I think that we misunderstood each other on the purpose of STM to particularly on the term "hardware trace": For more information see http://www.arm.com/products/system-ip/debug-trace/trace-macrocells-etm/coresight-system-trace-macrocell.php . This new user API is to manage trace resources (channels) and configuration of STM for the rest it's standard write only char driver to provide printf style debug interface. There is no interference with perf event infrastructure.
> > > See my detailed response for all your interrogations and my thoughts > about > > STE STM implementation below: > > > > On 25 May 2011 23:54, Deao, Douglas <d-d...@ti.com> wrote: > > > > > Sorry it took a while to get back to you guys. I was visiting customers > > > last week. Most of my comments are just highlighting the differences > between > > > TI's STM 1.0 driver and ST-E's STM 1.0 driver, but there are a few > > > questions, observations and suggestions. At the end I included some > > > discussion on TI's meta data and OST header requirements. > > > > > > I have not had a chance to look at your actual implementation yet. Did > you > > > do anything to abstract the actual HW transport ports and control > registers > > > from the higher level driver functions? > > > > > Yes, partially I think through IOCTLs & debugfs (see our stm.h userspace > > API) > > Any ioctls in addition to the ones defined in include/linux/perf_event.h > will need to be coordinated with the perf developers. > > Regarding a debugfs interface, you need to consider that all you cannot > build stable interfaces in debugfs by definition. If you want to have > long-term support for your subsystem, you would need a new file system. > OK > > > > I am especially interested in details of what you guys have in mind for > a > > > "common trace framework to receive STM drivers". If by framework you > mean > > > well defined APIs that are implemented for specific devices, then I > think we > > > are in agreement. What Michael and I have talked about is a common STM > user > > > mode experience across all Linaro supported devices, making Linux user > mode > > > code 100% portable between our devices. > > > > > For my point of view, the trace device framework must ease the > integration > > of new hardware trace drivers in the kernel > > (not only STM MIPI) to present standard hooks in current trace > > infrastructure, but it can cover a common STM userspace > > API too. > > Can you explain the difference between hardware trace drivers and PMU > drivers? What does the common infrastructure for trace drivers do > that is not already handled by ftrace or perf? > STM is more an hardware to extract printf like traces and far less intrusive, it can be use instead of internal trace ring buffer to extract ftrace or perf results through an external probe. > > > > I am thinking that for each unique pid a channel should be assigned > when > > > the device is opened. I would guess you are keeping a channel table > around > > > and write() just checks the table for a pid assignment (no time to look > at > > > your implementation yet), if none is found the first free channel is > used. > > > If you moved this function back to open then you could do the IOCTL > > > STM_GET_CHANNEL_NO anytime, not just after the first write. > > > > > The reason behind this behavior is for our current STM user lib which > open > > "/dev/stm" and alloc/free channels with > > IOCTL and never use write operation (only mmap + direct write) and in > this > > case we don't want to loose a channel. > > I think we can change this behavior. We can support multiple channels > > allocated for one Process to avoid contention > > in multi-threaded process. > > /dev/stm does not sound particularly hardware independent, i.e. it would > not be portable to other architectures. The kernel interface should realy > abstract such differences. Why do you need an extra character device > besides > the perf file descriptor? > > Arnd > Philippe
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
