Re-enable DMA trace initialization in Zephyr

[marc-hb]

Just a first part. The DMA trace with the SOF dictionary works in my workspace but I'm still cleaning up the rest.

[lyakh]

Good that you've posted this, nice to see that all those parts can be safely re-enabled and the respective #ifdefs can be removed. Would it be better to wait with merging this PR until we can actually enable DMA traces with SOF+Zephyr? Firstly to avoid adding unused code to the build and secondly to first get a chance to review and test the whole set?

[marc-hb]

On one hand it would be better to turn this on once the corresponding tests are ready[*]. On the other hand a ​"Continuous Integration" and "Continuous Review" approach is also valuable, it can be harder to find reviewers for large PRs and I'm one of the (few?) people who looks at tests results every day. Moreover this PR is just removing 2 hacks and fixing one minor issue, the tracing code is unused only in Zephyr and this PR makes the initialization code actually run in Zephyr, so it's not really unused.

Also keep in mind I'm testing this code (+ other work in progress) many times every day. In fact I've been sitting on these specific patches for a long time and I waited to have the sof-logger fully working before submitting them.

The next PRs should be bigger I promise :-)

[*] In fact I've already been spending a massive amount of time on the test side, see the large web of links from thesofproject/sof-test#297

https://sof-ci.01.org/sofpr/PR4452/build9577/devicetest is all green.

[lgirdwood]

@marc-hb @lyakh do we have consensus when to merge, I dont see any harm now, unless someone tells me it will get in the way of some other work until DMA is ready ?

[lyakh]

@marc-hb @lyakh do we have consensus when to merge, I dont see any harm now, unless someone tells me it will get in the way of some other work until DMA is ready ?

@lgirdwood IMHO usually it's better to only add or enable code when it is used and can be tested, but in principle it should be fine to merge this now too, seems harmless enough.

would like to clarify what the DMA trace task would do after this

[lyakh]

@marc-hb @lyakh do we have consensus when to merge, I dont see any harm now, unless someone tells me it will get in the way of some other work until DMA is ready ?

@lgirdwood IMHO usually it's better to only add or enable code when it is used and can be tested, but in principle it should be fine to merge this now too, seems harmless enough.

In fact I've looked again and it seems to me that after this PR the DMA trace task would begin scheduling periodically under Zephyr. And this doesn't work yet, right? Do we really want this even if this isn't causing any problems, which I'm not sure about?

[marc-hb]

In fact I've looked again and it seems to me that after this PR the DMA trace task would begin scheduling periodically under Zephyr. And this doesn't work yet, right? Do we really want this even if this isn't causing any problems, which I'm not sure about?

It used to work until your commit your PR zephyr: switch over to a simple priority-based LL scheduler
#4377, thanks for the warning! See my recent comment there. Downgrading this to draft until this scheduler situation is resolved.

[marc-hb]

Superset #4503 was merged.