-
Notifications
You must be signed in to change notification settings - Fork 309
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zephyr: sof-logger #4503
Merged
Merged
zephyr: sof-logger #4503
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
45df060
zephyr_ll.c: declare missing ll_tr trace context
marc-hb a985f95
cavs/platform.c: don't guard trace initialization with #ifdef ZEPHYR
marc-hb f787e5d
ipc3/handler.c: re-enable DMA trace for Zephyr
marc-hb 98b55c8
trace: add 'atomic' argument to mtrace_dict_entry()
marc-hb c8f178f
trace: move CONFIG_TRACEM implementation up a couple levels
marc-hb 5ea6e5b
trace: add _log_nodict() and enable DMA trace for Zephyr
marc-hb File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you, please, rename
ll_tr
to something else, maybezll_tr
.In i.MX case, we don't want to use
zephyr_ll
since this is limited toTIMER_DOMAIN
(see here) and we are usingDMA_DOMAIN
.We want, for now, to keep using
ll_schedule
.Therefore, when compiling this, for i.MX, I get:
zephyr_ll.c:22: multiple definition of ll_tr;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to help but you're asking me to fix a problem with a configuration that is currently not possible in this branch, probably only on your branch. With this branch there is AFAIK no way to compile
ll_schedule.c
in Zephyr. After a fair amount of time spent realizing this I tried this naive:... but that does not work because:
In other words @lyakh in PR #4377 made
zephyr_ll.c
andll_schedule.c
somehow mutually exclusive even before this PR does withll_tr
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forgot this: a simple rename and declaration of
DECLARE_TR_CTX(Zll_tr,...
inzephyr_ll.c
is not possible becausell_tr
is used in at least 5 different C files, some shared across both Zephyr and non-Zephyr.Maybe I can figure out something else but I need to reproduce your problem first, so if you have a way to compile both
zephyr_ll.c
andll_schedule.c
together please submit it first.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@iuliana-prodan @dbaluta so DMA domain is becoming problematic as it does not scale well to multiple low latency streams (it's simple and great when there is a smaller number of streams though) or when the codec is driving the clocks.
I think we need to improve the DMA driven domain as follows.
Today we have
We need to make one change to support DMA domain here and make it synchronous. Step 1 should also be able to be
This means we keep the DMA based time domain and we can also scale all LL streams to this time domain.
Fwiw, this is how things worked on OMAP4, the topology would tell FW which DMA channel was to be used as time domain. If the DMA channel stopped then FW had to then use the DMA channel from the next running stream. PR #4471 is allowing the trigger(start|stops) to be synchronised and this would mean that DMA IRQs could also be synchronised.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@iuliana-prodan can you please:
zephyr_ll.c
andll_schedule.c
together so I can reproduce the problem specific to your branch. It does not matter to me if that draft never gets merged, I just need a way to reproduce your problem if you would like me to solve it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lgirdwood @marc-hb I've created a pull request with my fixes for i.MX with Zephyr -see #4524
Now we can run successfully playback and record scenarios with Zephyr.
@lgirdwood until we can extend
ll_zephyr
with DMA_IRQ (I've created a feature request for this - #4523) we'll be usingll_schedule
. Hope it's ok with you.@marc-hb using my pull request (#4524) and enabling dma-trace you'll run into
zephyr_ll.c:22: multiple definition of ll_tr;
That's because in commit 1 I'm adding
ll_schedule
to be compiled for Zephyr and thezephyr_ll
is added mandatory for all platforms - see here.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As explained in #4524 and #4525 it's not possible to compile-test any CONFIG_IMX yet but if I understood this issue correctly the latest version should be compatible with your branch, please test it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@iuliana-prodan I commented in your PR - maybe you shouldn't include both ll_zephyr.c and ll_schedule.c in your builds?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @lyakh.
I've replied to you in my PR.
Please let me know if you agree with my proposed solution - from here, and I can make the changes and update that PR.