Repository navigation
SOF DMA Trace: avoid logs clearance at runtime suspend/resume #306
Description
We have enabled SOF Runtime Power Management on SKL+ platforms, where we will actually power off/on Audio DSP at suspend/resume, there, DMA trace will be re-initialized, those logs happened before last suspend will be overwritten from offset 0 at once after ADSP is resumed.
To fix this, we can do some extension to BDL setup function, e.g. add a member host_init_offset to store the last trace offset, and copying new generated trace logs to buffers(BDL entries) from this offset, with this implemented, FW won't overwrite the existed logs happened before suspend.
It is somehow different for SKL- platforms where we use GPDMA for DMA trace, we need to implement non-0 offset support to implement the similar feature, please refer to this:
thesofproject/sof#544
Activity
ranj063 commentedon Nov 20, 2018
@keyonjie we dont have suspend/resume on SKL- platforms yet
keyonjie commentedon Nov 20, 2018
thanks for clarification, then we can focus on skl+ implementation ATM.
plbossart commentedon Nov 20, 2018
well we don't even have SKL- support since the code doesn't even boot properly with the trace issues, so suspend-resume is not even a problem at this point. Gah.
lgirdwood commentedon Nov 22, 2018
@keyonjie will this be a driver only fix, or does it need FW change too ?
keyonjie commentedon Nov 23, 2018
@lgirdwood this will be driver only fix for SKL+ platforms.
xiulipan commentedon Nov 23, 2018
@keyonjie
So this is for DMA trace only. I think for error trace we need some FW change too.
[-]SOF Trace: avoid logs clearance at runtime suspend/resume[/-][+]SOF DMA Trace: avoid logs clearance at runtime suspend/resume[/+]keyonjie commentedon Nov 23, 2018
@xiulipan right, it's for DMA trace only. for etrace, we need think about new solution to avoid clearance.
plbossart commentedon Nov 26, 2018
@keyonjie Rather than muck with DMA/BDL programming, I thought the recommendation was to save all traces in host memory before suspend?
keyonjie commentedon Nov 27, 2018
@plbossart that's another thought, but I believe that's belong to user space(e.g. running tools such as sof-logger all the time and saving output to an log file, similar to kern.log or syslog?)
keyonjie commentedon Nov 27, 2018
anyway, porting our DMA trace log to standard system trace is good idea.
plbossart commentedon Mar 24, 2019
@ranj063 @keyonjie is this trace support across suspend-resume a planned activity or is this dropped? There's been no update since November 26.
ranj063 commentedon Mar 24, 2019
@plbossart I think this issue has been tabled for far too long. Let me check with @keyonjie this week and maybe see if @mengdonglin can assign someone else if Keyon is busy with WoV.
kv2019i commentedon Apr 3, 2019
Hey folks (especially @ranj063 and @keyonjie), I now made a pair of patches that makes "sof-logger -t" work more consistantly over suspends (both runtime and S3) -> PR781 linked above
This basicly allows to get the traces if you have sof-logger running. If sof-logger is not running and you start it later, you'll get traces since last resume (but not before). The patched sof-logger works also with S3/D3 suspends (so not just with runtime pm).
This is not necessarily a full replacement for Keyon's patchset, but it does improve trace consistency quite a bit already.
ranj063 commentedon Apr 3, 2019
plbossart commentedon May 27, 2020
@keyonjie @kv2019i is this still relevant?
plbossart commentedon Aug 11, 2020
@keyonjie @kv2019i no answer -> closing