[Sound-open-firmware] [PATCH v3 07/14] ASoC: SOF: Add DSP firmware logger support

[Pierre-Louis Bossart]

On 12/12/18 10:12 AM, Takashi Iwai wrote:
> 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 at linux.intel.com>
>>>>
>>>> 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. I'll rework the commit message for the third time to be clearer...