Trace: Remove ctx dependency from current logging system

[btian1]

This is a preparation for SOF logging to zephyr interface, IPC3 logging need context support, it is not must, and verified with #8725 , so remove these dependencies and will use another new PR to make SOF with zephyr logging interface.

[lgirdwood]

the last commit in the series is huge, impossible to review (it seems trivial, but still would be good to at least have a chance), and has a high breakage probability - almost any other PR, that gets merged before this one would break it. What I personally would do instead, I'd add a new interface (maybe trace_*() or log_*()) and gradually move files over to it - one subsystem at a time, one PR for IPC, one PR for schedulers, etc. Then after all are migrated, you just remove the tr_*() API

This would simplify the merge, i.e. not a big bang and reduced change of conflict races with other PRs. @btian1 one more thing, I would show the log output before/after the change in the PR introduction.

[dbaluta]

Can you please try to address at least some of the checkpatch.pl errors:

for example this:

WARNING: macros should not use a trailing semicolon
#243: FILE: src/include/sof/trace/trace_nonzephyr.h:137:
+#define trace_check_size_uint32(a) \
+	CT_ASSERT(sizeof(a) <= sizeof(uint32_t), "error: trace argument is bigger than a uint32_t");

I think it is relevant.

[btian1]

Can you please try to address at least some of the checkpatch.pl errors:

for example this:

WARNING: macros should not use a trailing semicolon
#243: FILE: src/include/sof/trace/trace_nonzephyr.h:137:
+#define trace_check_size_uint32(a) \
+	CT_ASSERT(sizeof(a) <= sizeof(uint32_t), "error: trace argument is bigger than a uint32_t");

I think it is relevant.

@dbaluta , this is keep as origin, I change nothing, you can check: https://github.com/thesofproject/sof/blob/main/src/include/sof/trace/trace.h#L272

still need help from you for IPC3 logging compare as Liam requested, it should be fine, I will try to finish this patch tomorrow.

[dbaluta]

@btian1 Please let me know when the patches are in a final form and will try to give them a test

[btian1]

@btian1 Please let me know when the patches are in a final form and will try to give them a test

@btian1 Please let me know when the patches are in a final form and will try to give them a test

Thanks, @dbaluta , just try with current version of this PR, it should be done now.

[btian1]

@kv2019i @lgirdwood @lyakh @dbaluta , codestyle problem is origin issue, if we want to fix, we can fix with another PR, this PR does not change those code actually.

Regarding the fuzzy error, it may related with #8632 patch merge, please notice.

[btian1]

@dbaluta , could you try with this PR for IPC3 logging? I don't want make pause here due to CNY holiday.

[dbaluta]

@LaurentiuM1234 can you please try to see if logging still works after this PR?

@btian1 can you please confirm the testing conditions? Is it with XTOS right?

[LaurentiuM1234]

@LaurentiuM1234 can you please try to see if logging still works after this PR?

@btian1 can you please confirm the testing conditions? Is it with XTOS right?

tested on QM with Zephyr hybrid build (and CS42888 tplg) and all's good. For reference, I'm attaching a snippet of how the logs look like w/ this patch. I'm assuming this behaves the same as XTOS since they use the same infrastructure.

[dbaluta]

@LaurentiuM1234 can you post a snippet of the log w/o the patch. It looks like now the component is shown as "Unknown". I wonder if w/o the patch the real component is correctly shown or there is an earlier bug.

[LaurentiuM1234]

@LaurentiuM1234 can you post a snippet of the log w/o the patch. It looks like now the component is shown as "Unknown". I wonder if w/o the patch the real component is correctly shown or there is an earlier bug.

sorry for the long delay. Attaching snippet (8QM, WM8690, SOF main (557e581ca8a607ace0833b30c3ec5e0c87471ff4)):

[dbaluta]

@btian1 looks like with your patch we lose ability to get the component for which the log was generated. Is this intended right?

If so then maybe we can remove that column from sof-logger output.

What's your take on this?

[btian1]

then maybe we can remove that column from sof-logger output.

What's your take on this?

Thanks, @dbaluta @LaurentiuM1234 , due to UID was removed, then sof-logger unable to find each component name for logging, as you suggested, I removed this part print from sof-logger, please try with full PR with rebuild sof-logger again, it should be fine now with/without this patch, the log should be same.