audio: module_adapter: remove unnecessary IRQ lock/unlock#10974
Open
kv2019i wants to merge 1 commit into
Open
Conversation
In the past, the module adapter prepare and free methods called buffer_attach() and buffer_detach() directly. To call these methods safely, it was required to disable IRQs. See commit 3e3d0cd ("buffer: prevent cache corruption") for history and rationale. However, in commit ecc55f8 ("buf: split sink_list connector to 2 fields") the direct calls to buffer.h were removed. The locks were still kept. Reviewing the code today, the protected operations work on buffer list maintained in "mod->raw_data_buffers_list". This list is used only by the module adapter itself. External connections go through component "dev->bsink_list" and "dev->bsource_list", which are separate objects and only used in prepare() by the module adapter. As the pipeline code will ensure module's copy() is not called concurrently with prepare() and free(), it is no longer required to use locks to protect against list operations on the internal list. Removing direct calls to disable interrupts allows to run this code in user-space. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
kv2019i
requested review from
abonislawski,
Copilot,
jsarha,
lgirdwood,
lyakh,
softwarecki,
tmleman and
wjablon1
Collaborator
Author
|
For context, related to #10558 |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR removes local IRQ disable/enable around internal raw_data_buffers_list list updates in the module adapter’s prepare()/free() paths. This aligns the implementation with the current design where these buffers are owned and managed solely by the module adapter, and helps enable running this code in user-space.
Changes:
- Removed
irq_local_disable()/irq_local_enable()guardingraw_data_buffers_listprepend/delete operations inmodule_adapter_prepare(). - Removed the same IRQ guard around
raw_data_buffers_listdeletions inmodule_adapter_free(). - Cleaned up now-unneeded
flagslocals associated with the removed IRQ locking.
tmleman
approved these changes
Jul 3, 2026
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.
In the past, the module adapter prepare and free methods called buffer_attach() and buffer_detach() directly. To call these methods safely, it was required to disable IRQs. See commit 3e3d0cd ("buffer: prevent cache corruption") for history and rationale.
However, in commit ecc55f8 ("buf: split sink_list connector to 2 fields") the direct calls to buffer.h were removed. The locks were still kept.
Reviewing the code today, the protected operations work on buffer list maintained in "mod->raw_data_buffers_list". This list is used only by the module adapter itself. External connections go through component "dev->bsink_list" and "dev->bsource_list", which are separate objects and only used in prepare() by the module adapter.
As the pipeline code will ensure module's copy() is not called concurrently with prepare() and free(), it is no longer required to use locks to protect against list operations on the internal list. Removing direct calls to disable interrupts allows to run this code in user-space.