userspace: preparatory patches for multicore LL scheduler#10949
Conversation
Memory zones are only used with IPC3, mark them as such. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
There was a problem hiding this comment.
Pull request overview
This PR introduces preparatory changes to support upcoming userspace, multicore low-latency (LL) scheduling work (part of #10945), focusing on making key runtime objects (LL scheduler/domain + DMA channel arrays) more compatible with Zephyr userspace allocation and coherency needs.
Changes:
- Track and use an allocation heap for Zephyr-native
sof_dmachannel arrays, enabling heap-correct frees. - Adjust userspace LL task/domain initialization to allocate and initialize objects suitable for userspace operation (e.g., dynamic semaphore allocation).
- Limit deprecated IPC3 buffer caps-to-flags conversion to IPC major 3 builds.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| zephyr/include/sof/lib/dma.h | Extends struct sof_dma (Zephyr native) to retain the heap used for channel allocations. |
| src/schedule/zephyr_ll.c | Updates userspace LL task allocation behavior (explicit zero-init) and sets coherent flags for scheduler data. |
| src/schedule/zephyr_domain.c | Moves userspace LL per-core semaphore allocation into privileged thread init, and refines kernel-space init behavior. |
| src/lib/dma.c | Allocates/frees Zephyr-native DMA channel arrays via sof_heap_alloc/free and selects user heap when invoked by a userspace thread. |
| src/ipc/ipc-helper.c | Guards deprecated IPC3 caps conversion/warning under CONFIG_IPC_MAJOR_3. |
kv2019i
left a comment
There was a problem hiding this comment.
One minor change on commented code, but looks good otherwise.
| static int dma_init(struct sof_dma *dma) | ||
| { | ||
| struct dma_chan_data *chan; | ||
| struct k_heap *heap = thread_is_userspace(k_current_get()) ? sof_sys_user_heap_get() : NULL; |
There was a problem hiding this comment.
Not 100% sure about this. I've been trying to make the heap decision a built-time choise (if LL_USER enabled in build, use sof_sys_user_heap_get()) to make it easy to understand in which circumstances the code path is taken.
This adds the calling thread as a variable to decide how resources are allocated. But I get in this case we could have mixed use of DMA channels both from kernel and user threads, so the simple logic is not sufficient. And the heap used is stored in "dma->heap", so this stays correct. Hmm, this is a different pattern, but leaning towards +1 for this.
There was a problem hiding this comment.
@kv2019i I tried to minimise changes - for non-userspace cases at least. I've just checked, using sof_sys_user_heap_get() unconditionally works too. What's your preference - keep this or make it depend on IS_ENABLED(CONFIG_...)?
When initialising in userspace use the userspace heap for channel memory allocations. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Instead of allocating semaphores during global initialisation, do that later when initialising the domain for specific cores. This also automatically grants access rights to the allocating thread. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
This is needed at least to set the .priv_data pointer to NULL. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Also when userspace is used scheduler instances have to be allocated uncached. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
a part of #10945 that can be applied now