[Sound-open-firmware] RFC patches to change debugfs trace behaviour

Kai Vehmanen kai.vehmanen at linux.intel.com
Wed Apr 10 20:00:17 CEST 2019


Hi all,
here goes first post to this list -- nice to be back working with 
open-source audio projects! :)

I've been looking at the SOF debugfs trace implementation a bit. I've made 
a few small fixes, but it would seem there are some limitations in how it 
works now. The FW is filling the 64K trace buffer at its own pace (e.g. 
not stopping for overrun). With current implementation, the write offset 
is also reset on suspend/resume cycles.

For the trace client (e.g. sof-logger), the interface has issues if 
the client is not run all the time. It has no way to detect overruns
nor to discover where the FW is writing. But OTOH, if the trace client
is run all the time (which is the expected usage model for debug), it 
is ok.

I have a RFC patchset in github that fixes one common gap -- e.g. trace 
continuity over suspend/resume cycles:
[RFC] ASoC: sof: force end-of-file for debugfs trace at suspend
https://github.com/thesofproject/linux/pull/781

... but this does make the SOF trace interface further specialized. 
Specifically my patchset forces the trace client to reopen the debugfs 
node by emitting EOF when FW suspends. I have a matching patch to 
sof-logger [1] that handles this without bothering the user. Doing 'cat 
/sys/kernel/debug/sof/trace' is not broken and still wworks still, but 
runtime PM the tracing ends frequently and you need at least some 
scripting to re-run cat, or use 'sof-logger -t'.
	
So with that long introduction, I'm seeking your input whether this an ok 
approach to take and/or does this break some existing workflows to consume 
the traces?

[1] https://github.com/thesofproject/sof/pull/1221

Br, Kai


More information about the Sound-open-firmware mailing list