On 10/6/21 6:23 AM, Mark Brown wrote: > On Wed, Oct 06, 2021 at 02:06:26PM +0300, Peter Ujfalusi wrote: >> Hi, >> >> The aim of this series is to clean up, make it easier to interpret and less >> 'chatty' prints aimed for debugging errors. >> >> For example currently the DSP/IPC dump is printed every time we have an IPC >> timeout and it is posible to lost the first and more indicative dump to find the >> rootcause. > > You might want to look at tracepoints and/or trace_printk, apart from > anything else they're very useful for flight recorder style applications > since they're very low overhead and have comparitively speeaking lots of > storage available. Yes, for the dev_dbg() I am thinking of a transition to tracepoints indeed. That would be most interesting for IPC, stream events, state machines, etc. We'll probably want to gather kernel and firmware traces with the same tools as well, something that should already be supported in hardware and not using due to inertia, lack of time, etc. But the changes that Peter did for this series are for 'major' issues that should typically not happen, rare events using limited bandwidth and usually not recoverable without a DSP reset. It's the kind of things we want end-users to report with 'alsa-info'.
