Repository navigation
Audio: dax: cache control parameters from the configuration thread - #11350
Merged
Merged
Conversation
The DAX module can only run in a kernel-mode DP thread:
- its shared state is serialised with k_spin_lock(), which needs
privileged interrupt masking and is therefore not usable from a user
thread,
- the cross-instance DAX instance manager is a kernel-only static in
base firmware .bss and is not mapped into a DP module memory domain,
- not every helper it calls from module context (for instance
comp_data_blob_set()) is exported as a syscall.
Reject it at build time with an explicit #error, and document the
constraint in the module Kconfig help. The guard also covers the LLEXT
variant.
Signed-off-by: junlai <jun.lai@dolby.com>
Collaborator
|
Can one of the admins verify this patch?
|
sof_dax_set_configuration() and sof_dax_process() run in different threads, but the configuration path currently writes struct sof_dax directly while the processing thread periodically uses it, causing unsynchronized concurrent access. Instead, cache all control values and the tuning file in the configuration thread and apply them from sof_dax_process() only. Parameter parsing that touches the DAX context or the DAX library is also restricted to the processing thread, and dax_ctx is updated only after a cached value has been applied successfully. The tuning file is still only swapped into the DAX context for later use. Instance priority registration uses the cached output device, because dax_ctx is not updated before the stream starts. Signed-off-by: junlai <jun.lai@dolby.com>
checkupup
force-pushed
the
main_dax_cache_params
branch
from
October 24, 2026 01:59
4adf7c7 to
fb0ecb7
Compare
checkupup
marked this pull request as ready for review
October 26, 2026 10:01
checkupup
requested review from
dbaluta,
kv2019i,
lbetlej,
lgirdwood,
mmaka1,
plbossart and
ranj063
as code owners
October 26, 2026 10:01
softwarecki
approved these changes
Oct 29, 2026
lgirdwood
reviewed
Oct 29, 2026
| * - a explicit persist/scratch/IO heap buffer size is required for user mode (default is 20KB) | ||
| */ | ||
| #if CONFIG_USERSPACE && !CONFIG_SOF_USERSPACE_PROXY | ||
| #error "Dolby DAX is not user-mode safe" |
Member
There was a problem hiding this comment.
In the not to distant future, all modules will run in userspace.
Are all the changes needed to support userspace in the open source module parts or both open and closed parts of the module ?
Contributor
Author
There was a problem hiding this comment.
Runing DAX module in userspace (CONFIG_USERSPACE=y) works without issues, but the DAX module does not support CONFIG_SOF_USERSPACE_APLICATION=y (the "user-mode" mentioned in the comments). Only run DAX in userspace with an userspace proxy
Member
There was a problem hiding this comment.
ok, so its just the opensource code then that need updates and nothing blocking in the binary DAX library ?
lgirdwood
approved these changes
Nov 3, 2026
Member
|
not tested by internal CI. |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
sof_dax_set_configuration() and sof_dax_process() run in different threads, but the configuration path currently writes struct sof_dax directly while the processing thread periodically uses it, causing unsynchronized concurrent access.
Instead, cache all control values and the tuning file in the configuration thread and apply them from sof_dax_process() only. Parameter parsing that touches the DAX context or the DAX library is also restricted to the processing thread, and dax_ctx is updated only after a cached value has been applied successfully. The tuning file is still only swapped into the DAX context for later use.
Instance priority registration uses the cached output device, because dax_ctx is not updated before the stream starts.