audio: copier: avoid IRQ lock/unlock in chmap code#10972
Conversation
Copier set_chmap() blocks IRQs to atomically update the converters. This code is not safe to be moved to user-space, so replace the locks with calls to block LL scheduler execution. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
There was a problem hiding this comment.
Pull request overview
Updates the copier channel-map update path to avoid disabling/enabling IRQs when building with user-space LL scheduling, switching to the LL scheduler’s per-core lock for atomic updates of converter function pointers and channel maps.
Changes:
- Add LL scheduler domain header to access
user_ll_lock_sched()/user_ll_unlock_sched(). - Use LL scheduler locking in
set_chmap()underCONFIG_SOF_USERSPACE_LL, otherwise keep the IRQ disable/enable path.
| #include <rtos/interrupt.h> | ||
| #include <sof/ipc/msg.h> | ||
| #include <sof/ipc/topology.h> | ||
| #include <sof/schedule/ll_schedule_domain.h> | ||
| #include <rtos/interrupt.h> |
There was a problem hiding this comment.
Not part of this PR.
|
For context, related to #10558 |
|
|
||
| /* Atomically update chmap, process and converters */ | ||
| /* Atomically update chmap, process and converters. | ||
| * In user-space builds irq_local_disable() is privileged, |
There was a problem hiding this comment.
irq_local_disable() is privileged in all builds ;-)
| user_ll_lock_sched(dev->pipeline->core); | ||
| #else | ||
| irq_local_disable(irq_flags); | ||
| #endif |
There was a problem hiding this comment.
does it actually make sense to change the copier channel map while it's already processing data? If not, if this function should only run when there's no active streaming taking place, maybe we could just put a status check in the beginning of this function and avoid locking entirely?
Copier set_chmap() blocks IRQs to atomically update the converters. This code is not safe to be moved to user-space, so replace the locks with calls to block LL scheduler execution.