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