wip: alloc: virtual regions and vpage allocator. #10281

lgirdwood · 2025-10-05T18:19:18Z

WIP: To be split into smaller patches.

Add a simple contiguous virtual page allocator.
Add a virtual region per pipeline/DP module.
Integrate into mod_alloc() and mod_free().
TODO: Make sure all pipeline resources exist within same virtual
region.

lgirdwood · 2025-10-05T18:20:37Z

@jsarha fyi - this will be needed by your updates.

lyakh · 2025-10-06T07:19:21Z

zephyr/lib/pacovr.c

+		return;
+
+	/* simple free, just increment free count, this is for tuning only */
+	p->batch_free_count++;


should this be decremented during allocator's alloc() call?

no, intention here is we should be able to see if this is > 0 then there is room for heap optimization.

lyakh · 2025-10-06T07:40:18Z

zephyr/lib/vpages.c

+
+	/* map the virtual blocks in virtual region to free physical blocks */
+	ret = sys_mm_drv_map_region_safe(page_context.virtual_region, vaddr,
+			0, pages * CONFIG_MM_DRV_PAGE_SIZE, SYS_MM_MEM_PERM_RW);


this is allocating physical pages from anywhere in L2 memory?

Free physical pages from L2 SRAM

Free physical pages from L2 SRAM

@lgirdwood right, but shouldn't this be allocating from a pre-allocated set of pages for this "heap" or am I misunderstanding the concept?

lyakh · 2025-10-06T07:58:30Z

zephyr/lib/pacovr.c

+	/* allocate memory */
+	ptr = p->batch_ptr;
+	p->batch_ptr += size;
+	p->batch_used += size;


are "batch" and "scratch" allocator names commonly used? I found a couple of references to scratch allocators, e.g. https://stackoverflow.com/questions/74956010/what-are-the-differences-between-block-stack-and-scratch-allocators#75044083 but there it's defined as "once allocated, never freed," similar to this your batch allocator?

and I've also found scratch memory as "temporary", but lets rename based on use. i.e. static and dynamic

jsarha

It should be pretty straight forward to integrate this with my IPC code and the latest version of mod_alloc() PR. Could not find anything wrong in the page allocator code either.

jsarha · 2025-10-06T21:31:16Z

src/audio/module_adapter/module/generic.c

 	switch (container->type) {
 	case MOD_RES_HEAP:
+#if CONFIG_SOF_PACOVR
+	/* do we need to use the scratch heap or the batch heap? */


I do not think this would work. Its not guaranteed that memory allocated in initialization phase is freed in also in initialization phase. For the moment there are modules freeing memory at initialized phase, that was allocated during init pahse.

It should not be too hard to write a single pacovr_free() that knows from the pointer's memory range if it was allocated from scratch or batch (=> dynamic or static) heap.

lgirdwood · 2025-10-08T12:06:49Z

@jsarha updated, can you try this with your topology patch for pipeline memory. Thanks !

Copilot

Pull Request Overview

This PR introduces a new PACOVR (Pre Allocated COntiguous Virtual memory Region) memory allocator system for pipeline resource management. The system provides virtual page allocation with both dynamic heap and static linear allocators built on top.

Adds virtual page allocator for contiguous memory regions
Implements PACOVR allocator with dynamic heap and static allocation capabilities
Integrates PACOVR into module allocation functions and pipeline lifecycle

Reviewed Changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
zephyr/lib/vpages.c	Virtual page allocator implementation with mapping/unmapping functionality
zephyr/lib/pacovr.c	PACOVR allocator with dynamic heap and static linear allocation
zephyr/include/sof/lib/vpage.h	API header for virtual page allocator
zephyr/include/sof/lib/pacovr.h	API header for PACOVR allocator
zephyr/Kconfig	Configuration options for PACOVR and virtual page elements
zephyr/CMakeLists.txt	Build system integration for new virtual memory files
src/include/sof/audio/pipeline.h	Pipeline structure extension to include PACOVR instance
src/audio/pipeline/pipeline-graph.c	Pipeline creation/destruction integration with PACOVR
src/audio/module_adapter/module/generic.c	Module allocation functions updated to use PACOVR
scripts/xtensa-build-zephyr.py	Additional symlink creation for firmware deployment

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

Copilot · 2025-10-08T12:08:07Z

zephyr/lib/vpages.c

+void vpage_free(void *ptr)
+{
+	k_mutex_lock(&page_context.lock, K_FOREVER);
+	vpages_free_and_unmap((uintptr_t *)ptr);


The variable 'ret' is not in scope here. The return value from vpages_free_and_unmap() should be captured and checked.

Suggested change

vpages_free_and_unmap((uintptr_t *)ptr);

int ret = vpages_free_and_unmap((uintptr_t *)ptr);

Copilot · 2025-10-08T12:08:07Z

zephyr/lib/vpages.c

+ * @brief Free virtual pages
+ * Frees previously allocated virtual memory pages and unmaps them.
+ *
+ * @param ptr


Missing documentation for the ptr parameter in the function comment block.

Suggested change

* @param ptr

* @param ptr Pointer to the start of the virtual memory pages to be freed.

* Must be page-aligned and previously allocated by the virtual page allocator.

Copilot · 2025-10-08T12:08:08Z

zephyr/include/sof/lib/pacovr.h

+ * @param[in] batch_size Size of the PACOVR batch region.
+ * @param[in] scratch_size Size of the scratch heap.


The parameter names in the documentation (batch_size, scratch_size) don't match the actual function parameter names (static_size, dynamic_size) in the implementation.

Copilot · 2025-10-08T12:08:08Z

zephyr/lib/pacovr.c

+	size_t total_size;
+
+	if (!static_size || !dynamic_size) {
+		LOG_ERR("error: invalid pacovr static size %d or dynamic size %d",


Using %d format specifier for size_t variables. Should use %zu for size_t to avoid potential format string issues.

Suggested change

LOG_ERR("error: invalid pacovr static size %d or dynamic size %d",

LOG_ERR("error: invalid pacovr static size %zu or dynamic size %zu",

Copilot · 2025-10-08T12:08:08Z

zephyr/lib/pacovr.c

+
+	/* check we have enough static space left */
+	if (p->static_used + size > p->static_size) {
+		LOG_ERR("error: pacovr static alloc failed for %d bytes, only %d bytes free",


Using %d format specifier for size_t variables. Should use %zu for size_t to avoid potential format string issues.

Suggested change

LOG_ERR("error: pacovr static alloc failed for %d bytes, only %d bytes free",

LOG_ERR("error: pacovr static alloc failed for %zu bytes, only %zu bytes free",

lyakh · 2025-10-13T15:07:31Z

zephyr/include/sof/lib/vpage.h

+ *
+ * @return Pointer to the allocated virtual memory region, or NULL on failure.
+ */
+void *vpage_alloc(uint32_t pages);


unsigned int?

lyakh · 2025-10-13T15:09:39Z

zephyr/lib/vpages.c

+ * @param ptr Pointer to store the address of allocated pages.
+ * @retval 0 if successful.
+ */
+static int vpages_alloc_and_map(uint32_t pages, void **ptr)


unsigned int

The function returns an error code as a negative value.

The function returns an error code as a negative value.

I meant for pages

lyakh · 2025-10-15T08:44:23Z

zephyr/lib/vpages.c

+			err, pages, page_context.total_pages, page_context.free_pages);
+	}
+	LOG_INF("vpage_alloc ptr %p pages %d free %d/%d", ptr, pages, page_context.free_pages,
+		page_context.total_pages);


else for this?

lyakh · 2025-10-15T08:50:14Z

zephyr/lib/vpages.c

+
+	/* allocate memory for bitmap bundles */
+	bundles = rzalloc(SOF_MEM_FLAG_KERNEL | SOF_MEM_FLAG_COHERENT,
+			  bitmap_num_bundles * sizeof(uint32_t));


we know the size from line 277, so bundles could be static?

softwarecki

Alright, here’s my round of nitpicking:

Looks like the ghost of memory zone is back, now wearing a fancy new name: region type. Quick question - will cacheability secretly depend on this type? Or is that just a plot twist waiting to happen?
Consider moving page mapping logic into vregion. For lifetime allocators, mapping pages progressively as needed could help reduce memory usage.
What is the purpose of the text region type? Whether vregion it's for a pipeline or a module, module executable code can be shared across multiple pipelines, so this seems wrong place.
Should memory management code be integrated into Zephyr? My understanding was that this was the intended direction for VMH.
Function naming feels inconsistent: *_vpages vs vregion_*. Worth aligning these.

I submitted a change request because this design looks like it's meant to replace the virtual heap, but it's missing a critical feature for deep buffering: predefined buffer sizes. The buffer size provided via ipc is only a hint. The firmware tries to allocate the largest possible buffer, and if memory is tight, it falls back to a smaller one. If the requested size exceeds available memory, allocation should still create the largest feasible buffer. Without predefined buffers it will lead to saturate memory and block further allocations. With predefined buffer sizes, we can pick the largest available option while leaving others for future allocations.

softwarecki · 2025-10-27T15:20:23Z

zephyr/lib/vpages.c

+ * @param ptr Pointer to store the address of allocated pages.
+ * @retval 0 if successful.
+ */
+static int vpages_alloc_and_map(uint32_t pages, void **ptr)


The function returns an error code as a negative value.

softwarecki · 2025-10-27T15:28:44Z

zephyr/lib/vpages.c

+	/* store the size and virtual page number in first free alloc element,
+	 * we have already checked for a free element before the mapping.
+	 */
+	for (int i = 0; i < VPAGE_MAX_ALLOCS; i++) {


Use page_context.num_elems as array index.

I've renamed the variable name, as this the number of elems in use rather than total number of elems to search.

maybe rather use lists to avoid scanning the array each time. Can be a follow-up optimisation

softwarecki · 2025-10-27T15:31:48Z

zephyr/lib/vpages.c

+ * Allocates virtual memory pages from the virtual page allocator.
+ *
+ * @param pages Number of 4kB pages to allocate.
+ * @retval ptr to allocated pages if successful.


There are not the ptr param.

softwarecki · 2025-10-27T15:34:15Z

zephyr/lib/vpages.c

+	int ret;
+
+	/* check for valid ptr which must be page aligned */
+	if (!ptr || ((uintptr_t)ptr % CONFIG_MM_DRV_PAGE_SIZE) != 0) {


IS_ALIGNED(ptr, CONFIG_MM_DRV_PAGE_SIZE)

optional || !page_context.num_elems.

softwarecki · 2025-10-27T16:10:29Z

zephyr/lib/vpages.c

+			LOG_DBG("found allocation element %d pages %d vpage %d for ptr %p",
+				i, page_context.velems[i].pages,
+				page_context.velems[i].vpage, ptr);
+


To eliminate the loop during page allocation, I suggest replace the removed element with the last item in the array. When allocating, the new element is always added at the end of the array.

page_context.num_elems--; page_context.velems[i] = page_context.velems[page_context.num_elems]; page_context.velems[page_context.num_elems].pages = 0; page_context.velems[page_context.num_elems].vpage = 0;

See the comment above about renaming the variable name to make meaning clearer..

softwarecki · 2025-10-27T16:51:59Z

zephyr/lib/vregion.c

+	/* calculate new heap object size for object and alignments */
+	heap_obj_size = aligned_ptr - heap->ptr + size;
+
+	/* check we have enough shared static space left */


softwarecki · 2025-10-27T16:52:25Z

zephyr/lib/vregion.c

+ * @param[in] vr Pointer to the virtual region instance.
+ * @param[in] ptr Pointer to the memory to free.
+ */
+void lifetime_free(struct vregion *vr, struct vlinear_heap *heap, void *ptr)


Missing static? lifetime_alloc is static.
Unused vr param.

softwarecki · 2025-10-27T16:57:28Z

zephyr/lib/vregion.c

+		return interim_alloc(vr, &vr->interim_shared, size, alignment);
+	case VREGION_MEM_TYPE_LIFETIME_SHARED:
+		return lifetime_alloc(vr, &vr->lifetime_shared, size,
+			alignment < CONFIG_DCACHE_LINE_SIZE ? CONFIG_DCACHE_LINE_SIZE : alignment,


Move this logic to the lifetime_alloc function.

This avoids the need to pass a shared flag today.

MAX(alignment, CONFIG_DCACHE_LINE_SIZE)

softwarecki · 2025-10-28T14:43:53Z

src/audio/module_adapter/module_adapter.c

+	}
+
+	/* allocate module in correct vregion*/
+	//TODO: add coherent flag for cross core DP modules


Consider adding the ZERO flag as well to replace rzalloc and avoid introducing additional memset calls.

softwarecki · 2025-10-28T14:49:38Z

zephyr/lib/vregion.c

+		return;
+	}
+
+	LOG_ERR("error: vregion free invalid pointer %p", ptr);


assert / panic?

lgirdwood · 2025-10-29T19:48:09Z

Alright, here’s my round of nitpicking:

Looks like the ghost of memory zone is back, now wearing a fancy new name: region type. Quick question - will cacheability secretly depend on this type? Or is that just a plot twist waiting to happen?

No ghosts here, the old zone was tied to very limited memory types and capabilities from ancient HW e.g. to make sure we didn't squander things like DMAable memory etc.

A region is partitioned into different areas tied to usage in our pipeline lifecycle. There is not type like DMA, LP, HP RAM etc its all just a virtual page. A region is partitioned this way as its easier to then assign attributes for sharing to different cores/domains and to also limit execution (all where permitted by HW).

Consider moving page mapping logic into vregion. For lifetime allocators, mapping pages progressively as needed could help reduce memory usage.

What would moving the remapping logic gain us ? Keeping the page allocator in a separate file/API keeps things simpler and exposes a page allocator API that can be used as needed independently of regions.

Agree, growing the lifetime allocators would save some pages if the runtime size < topology size, but this would lead to fragmentation. i.e. we have to track several virtual page (start, size) per pipeline. This could be something that can come later if we want to add more tracking, but keeping it simple is key at first.

What is the purpose of the text region type? Whether vregion it's for a pipeline or a module, module executable code can be shared across multiple pipelines, so this seems wrong place.

So its an optional usage partition with main use being TEXT for 3P DP modules. This keeps domain tracking easier and these pages will get RO EXEC permission for that domain.

Should memory management code be integrated into Zephyr? My understanding was that this was the intended direction for VMH.

Not atm. We need to get this working for audio as first step. If the vpages part is useful and generic, yes then it can go to Zephyr. The vregion part is probably too specific for our use case.

Function naming feels inconsistent: *_vpages vs vregion_*. Worth aligning these.

These are 2 separate APIs hence the difference in naming.

I submitted a change request because this design looks like it's meant to replace the virtual heap, but it's missing a critical feature for deep buffering: predefined buffer sizes. The buffer size provided via ipc is only a hint. The firmware tries to allocate the largest possible buffer, and if memory is tight, it falls back to a smaller one. If the requested size exceeds available memory, allocation should still create the largest feasible buffer. Without predefined buffers it will lead to saturate memory and block further allocations. With predefined buffer sizes, we can pick the largest available option while leaving others for future allocations.

This is factored in to the vregion size allocation for KPB and Deepbuffer like use cases today. i.e. SW has to include in the total memory budget. Its not perfect but I dont want to change too much here until pipeline 2.0 is completed (and at that point we can factor in the pipeline 2.0 changes around the buffers).

Currently the symlink for sof-ipc4/platform/sof-basefw.ri is not created. Fix this so that deployable builds can be copied directly to target from staging directory. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

Use a relative directory to script dir for default workspace if workspace is not set. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

Determine workspace if environment variable not defined. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

Add a simple virtual page allocator that uses the Zephyr memory mapping infrastructure to allocate pages from a virtual region and map them to physical pages. Due to simplicity, the number of allocations is limited to CONFIG_SOF_VPAGE_MAX_ALLOCS Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

Add support for per pipeline and per module virtual memory regions. The intention is to provide a single virtual memory region per pipeline or per DP module that can simplify module/pipeline memory management. The region takes advantage of the way pipeline and modules are constructed, destroyed and used during their lifetimes. 1) memory tracking - 1 pointer/size per pipeline or DP module. 2) memory read/write/execute permissions 3) memory sharing across cores and domains. 4) cache utilization. Modules and pipelines will allocate from their region only and this will be abstracted via the allocation APIs. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

Split into a common and heap derived allocator files. This is in preparation for memory regions. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

Allocate a vregion for pipeline module allocations. TODO: get the sizes from SW. TODO: abstract usage. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

Make DP modules use their own vregion for allocations. TODO: abstract usage. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

In preparation for pipeline specific memory regions make sure we get the pipeline prior to module memory allocation and pass teh pipeline to the module allocation API. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

Convert rmalloc and rballoc APIs to mod_alloc APIs. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

Use mod_alloc() API internally within fast-get() and fast-put() so that resources will be tracked at the module level. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

Add a module memory abstraction for virtual region usage. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

Fix valgrind memory leak warnings by freeing resources. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

Add support for cmocka usage of mod_alloc() APIs directly and indirectly via fast_get() APIs. This change means adding module API support into the fast-get-test since the module will track the resource usage. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

Kernel prints on IPC timeout, useful if oops is not generated. Developer aid. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

ipc4_audio_format_to_stream_params() will clear params and hence clear the previously set buffer size. Fix. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

No need to keep reallocating ipc4 stream params as IPC4 usage has a constant size with 0 extended data. Only allocate once. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

lyakh reviewed Oct 6, 2025

View reviewed changes

jsarha reviewed Oct 6, 2025

View reviewed changes

lgirdwood force-pushed the lrg/topic/vpages branch from 04bc5c1 to 987b31e Compare October 8, 2025 12:03

lgirdwood changed the title ~~wip: alloc: add scratch & batch heaps on top of virtual pages~~ wip: alloc: add static linear & dynamic zephyr heaps on top of virtual pages Oct 8, 2025

lgirdwood force-pushed the lrg/topic/vpages branch from 987b31e to 2146f88 Compare October 8, 2025 12:06

lgirdwood marked this pull request as ready for review October 8, 2025 12:07

Copilot AI review requested due to automatic review settings October 8, 2025 12:07

lgirdwood requested review from abonislawski, dbaluta, iuliana-prodan, kv2019i, lbetlej, mmaka1 and plbossart as code owners October 8, 2025 12:07

Copilot AI reviewed Oct 8, 2025

View reviewed changes

lyakh reviewed Oct 15, 2025

View reviewed changes

lgirdwood force-pushed the lrg/topic/vpages branch from 2146f88 to 9a9c238 Compare October 23, 2025 13:48

lgirdwood requested review from LaurentiuM1234, jxstelter, marcinszkudlinski, pblaszko and ranj063 as code owners October 23, 2025 13:48

lgirdwood force-pushed the lrg/topic/vpages branch from 9a9c238 to dd0601e Compare October 23, 2025 14:38

lgirdwood changed the title ~~wip: alloc: add static linear & dynamic zephyr heaps on top of virtual pages~~ wip: alloc: virtual regions and vpage allocator. Oct 24, 2025

lgirdwood mentioned this pull request Oct 24, 2025

Module api convert of aria, asrc, and copier #10284

Merged

softwarecki requested changes Oct 28, 2025

View reviewed changes

lgirdwood force-pushed the lrg/topic/vpages branch from dd0601e to b35816b Compare November 7, 2025 12:38

lgirdwood force-pushed the lrg/topic/vpages branch from 969bcfb to 3849b37 Compare November 13, 2025 16:22

lgirdwood mentioned this pull request Nov 14, 2025

Module api additions for cadence code and taking them into use #10366

Merged

lgirdwood force-pushed the lrg/topic/vpages branch 3 times, most recently from 57bcf94 to 582d804 Compare November 19, 2025 14:08

lrgirdwo added 5 commits November 19, 2025 16:06

scripts: create symlink for community base FW binary

bc2c514

Currently the symlink for sof-ipc4/platform/sof-basefw.ri is not created. Fix this so that deployable builds can be copied directly to target from staging directory. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

scripts: vscode: use script dir as fallback workspace

ab21ed6

Use a relative directory to script dir for default workspace if workspace is not set. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

scripts: use local directory if workspace not defined.

2ae160c

Determine workspace if environment variable not defined. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

lgirdwood force-pushed the lrg/topic/vpages branch from 582d804 to 1bfa302 Compare November 20, 2025 13:14

lrgirdwo added 12 commits November 20, 2025 16:07

module: memory: split out module memory API to new files.

b6b8c4c

Split into a common and heap derived allocator files. This is in preparation for memory regions. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

TEST: vregion: force enable for testing.

434047d

Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

wip: pipeline: add support for pipeline vregion.

fa64804

Allocate a vregion for pipeline module allocations. TODO: get the sizes from SW. TODO: abstract usage. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

wip: vregion: add DP module support for vregion.

dc3231e

Make DP modules use their own vregion for allocations. TODO: abstract usage. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

module: generic: use module memory APIs

de47258

Convert rmalloc and rballoc APIs to mod_alloc APIs. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

module: adapter: use module memory APIs

b31de06

Convert rmalloc and rballoc APIs to mod_alloc APIs. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

module: cadence: use module memory APIs

60ea9ae

Convert rmalloc and rballoc APIs to mod_alloc APIs. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

fast-get: use mod-alloc() API for fast-get internal usage.

7415622

Use mod_alloc() API internally within fast-get() and fast-put() so that resources will be tracked at the module level. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

module: vregions: add module support to use virtual regions

7e46033

Add a module memory abstraction for virtual region usage. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

cmocka: fix valigrind leaks

ef65da9

Fix valgrind memory leak warnings by freeing resources. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

lgirdwood force-pushed the lrg/topic/vpages branch from 1bfa302 to 5ea392c Compare November 20, 2025 16:12

lrgirdwo added 3 commits November 21, 2025 16:42

wip: trace: add a simple trace point tht kernel can print

3ab5d58

Kernel prints on IPC timeout, useful if oops is not generated. Developer aid. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

ipc4: helper: fix buffer size always being cleared after set.

fcdff70

ipc4_audio_format_to_stream_params() will clear params and hence clear the previously set buffer size. Fix. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

module_adapter: ipc4 stream params never have extended data

ec50b14

No need to keep reallocating ipc4 stream params as IPC4 usage has a constant size with 0 extended data. Only allocate once. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

lgirdwood requested a review from akloniex as a code owner November 21, 2025 17:52

This was referenced Dec 3, 2025

Code to decode pipeline create messages payload #10265

Open

New memory domain logic thesofproject/linux#5537

Open

	vpages_free_and_unmap((uintptr_t *)ptr);
	int ret = vpages_free_and_unmap((uintptr_t *)ptr);

	* @param ptr
	* @param ptr Pointer to the start of the virtual memory pages to be freed.
	* Must be page-aligned and previously allocated by the virtual page allocator.

		* @param[in] batch_size Size of the PACOVR batch region.
		* @param[in] scratch_size Size of the scratch heap.

	LOG_ERR("error: invalid pacovr static size %d or dynamic size %d",
	LOG_ERR("error: invalid pacovr static size %zu or dynamic size %zu",

	LOG_ERR("error: pacovr static alloc failed for %d bytes, only %d bytes free",
	LOG_ERR("error: pacovr static alloc failed for %zu bytes, only %zu bytes free",

wip: alloc: virtual regions and vpage allocator. #10281

Are you sure you want to change the base?

wip: alloc: virtual regions and vpage allocator. #10281

Uh oh!

Conversation

lgirdwood commented Oct 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lgirdwood commented Oct 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jsarha left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jsarha Oct 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lgirdwood commented Oct 8, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Copilot AI Oct 8, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Oct 8, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Oct 8, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Oct 8, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Oct 8, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

softwarecki left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

lgirdwood commented Oct 5, 2025 •

edited

Loading

jsarha left a comment •

edited

Loading

jsarha Oct 6, 2025 •

edited

Loading