On Wed, 12 Dec 2018 17:04:42 +0100, Pierre-Louis Bossart wrote: > > > On 12/12/18 5:11 AM, Takashi Iwai wrote: > > On Tue, 11 Dec 2018 22:23:11 +0100, > > Pierre-Louis Bossart wrote: > >> From: Liam Girdwood <liam.r.girdwood@xxxxxxxxxxxxxxx> > >> > >> This patch adds support for real-time DSP logging (timestamped events > >> and bespoke binary data) for firmware debug. The current solution > >> relies on DMA transfers to system memory that is then accessed by > >> userspace tools such as sof-logger. For Intel platforms, two types of > >> DMAs are currently used (GP-DMA for Baytrail/CherryTrail and HDaudio > >> DMA for SKL+) > >> > >> Due to historical reasons, the driver code follows the DSP firmware > >> conventions and refers to 'traces', but it is currently unrelated to > >> the Linux trace subsystem. Future solutions will include support for > >> more advanced hardware (e.g. MIPI Sys-T), additional formats and the > >> ability to enable/disable specific traces dynamically. > > So what's the reason not to use Linux standard tracing infrastructure? > > I obviously failed to convey the intent in the commit message :-( > > What we have today is just a DMA-based transfers of 'trace' data into > a ring buffer. That's it. it's very similar to what always existed on > Atom and Skylake, just more transparent and released for upstream > reviews this time. > > Is it optimal or final? Absolutely not. There will be evolutions such as > > A) support for multi-cores on the DSP side, each with their own > 'trace' capability. > > B) support for other hardware platforms which may not have a DMA. > > C) support for 'probes' to retrieve and inject PCM data into specific > firmware nodes. > > This patch does not create a new generic tracing infrastructure for > Linux. We are exploring ways by which this standard tracing > infrastructure can be used, we just haven't had time to look into it > as we focused on runtime_pm and new platforms first. > > Also we need to make sure the DSP traces are not defined for Linux > only, it's intended that the SOF firmware is used in non-Linux > environments, so we want to use what Linux provides, but not constrain > SOF to work for Linux only. > > Does this help? OK, that's fine. Liam and I talked about Linux tracing for SOF, and I thought this might be that. But this is rather a hardware data logging, so it's a different beast. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
