Zephyr trace dma #4866
Zephyr trace dma #4866
Conversation
From deep down trace.c:va_tracelog() up to the _log_message() level. Also rename va_tracelog() to the more specific dma_tracelog() Preparation to support the DMA trace in Zephyr. The only functional change in this commit is that DMA messages copied to the shared memory are not de-duplicated any more (a.k.a "adaptive rate limiting" or CONFIG_TRACE_FILTERING_ADAPTIVE). These are generally supposed to be high level hence rare enough; otherwise there is probably a "bigger problem". Signed-off-by: Marc Herbert <[email protected]>
As of July 2021 we support (too) many tracing options and this duplication is unfortunately the only way I found to support them all while giving the compiler the opportunity to optimize away as many strings as possible. Supported configurations: - Systems with limited memory and zero space for full strings, must use SOF dictionary only. - Systems with enough space for all strings to be in memory. - Anything in between - Support to duplicate only important message to both the DMA and the mailbox (the default) - CONFIG_TRACEM: supports duplicating ALL messages to both the DMA and the mailbox - CONFIG_TRACEV: supports deleting verbose statements at compile time to save space - CONFIG_TRACE: support turning off all traces at compile-time - SOF dict trace de-duplication a.k.a. "adaptive filtering" - Dynamic log levels per component - Redirection to Zephyr's shared memory tracing that requires full strings. Signed-off-by: Marc Herbert <[email protected]>
|
Could you add the SHA1 of original commit in the commit message? Like Everything passed in https://sof-ci.01.org/sofpr/PR4866/build10693/devicetest/ even before #4844 was merged. However the reproduction rate of #4558 was variable but never 100% and something extremely strange happened: https://sof-ci.01.org/sofpr/PR4866/build10693/devicetest/?model=CML_HEL_RT5682&testcase=check-suspend-resume-with-capture ran for only TWO suspend/resume cycles whereas most other platforms had THREE suspend/resume cycles... looking into it. EDIT, mystery solved: in the current PR test plan, this test is configured to run once PER (capture) device. |
|
SOFCI TEST |
|
Thanks @fredoh9 for extending the suspend-resume-capture test from 1 cycle per device to 5 cycles per device. After re-running this, the usual |
|
These patches exceed the memory available on APL with Zephyr and XCC, I was afraid of that: https://sof-ci.01.org/sofpr/PR4866/build10718/build/ |
|
Extending the suspend resume cycles a little bit also resurrected some old friends:
|
lyakh
requested review from
akloniex,
dbaluta,
lbetlej,
mmaka1 and
plbossart
as code owners
|
@marc-hb are any of those bugs caused by this PR or do they exist with upstream / Zephyr + gcc too? |
|
@lyakh I think we still need the HDA DMA fixes applied to the kernel too before these fails will turn green. I'll restart CI as I suspect these could be merged now. |
|
SOFCI TEST |
|
Nit: can you add one
#4908 has not been merged but somehow there is enough room right now: https://sof-ci.01.org/sofpr/PR4866/build10825/build/apl_zph.txt
No, these bugs been here forever (with XTOS and xcc) whereas these patches you're restoring in this PR were in the main branch for less than a few days. |
|
In https://sof-ci.01.org/sofpr/PR4866/build10825/devicetest/?model=CML_RVP_SDW&testcase=check-suspend-resume-with-playback-5 the whole system crashed short after |
I'd really like to get these patches from @marc-hb re-applied, let's see if they're still causing problems on CML