audio: fast-get: improve userspace compatibility by lyakh · Pull Request #10524 · thesofproject/sof

lyakh · 2026-02-05T13:59:09Z

remove unneeded syscalls and fix compilation warnings (part of #10469 )

Userspace modules should only call mod_fast_get() and mod_fast_put(), which already can cross into the kernel space on their own, so fast_get() and fast_put() themselves don't need to be syscalls. Remove their syscall implementations. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>

fast_get.c doesn't have a "trace context" - it doesn't have a DECLARE_TR_CTX() call. Hencs all calls to tr_err() and friends are wrong. Replace them with respective LOG_*() analogs. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>

Copilot

Pull request overview

This PR removes the syscall infrastructure for fast-get/fast-put functions and enhances userspace compatibility by enabling direct buffer sharing between user and kernel spaces. The changes eliminate unnecessary syscall overhead and prepare for more efficient memory management in userspace contexts.

Changes:

Converted fast-get functions from syscalls to regular functions, removing z_impl_* and z_vrfy_* wrappers
Added userspace-specific logic to handle memory partition grants for large buffers (> PAGE_SZ/2)
Updated logging from SOF trace macros (tr_) to standard LOG_ macros with conditional compilation for non-Zephyr builds

Reviewed changes

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

File	Description
zephyr/lib/fast-get.c	Removed syscall infrastructure, added userspace memory partition management, updated logging macros
src/include/sof/lib/fast-get.h	Simplified API by removing syscall declarations and conditional compilation
src/audio/module_adapter/module_adapter.c	Updated include path from platform/platform.h to sof/platform.h for consistency

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-02-05T14:08:46Z

zephyr/lib/fast-get.c

+			.size = ALIGN_UP(entry->size, CONFIG_MM_DRV_PAGE_SIZE),
+			.attr = K_MEM_PARTITION_P_RO_U_RO | XTENSA_MMU_CACHED_WB,


The constant XTENSA_MMU_CACHED_WB is Xtensa-specific but is used without architecture-specific guards. If CONFIG_USERSPACE is enabled on a non-Xtensa platform, this will cause a compilation error. Consider using architecture-specific conditionals or defining a platform-agnostic cache attribute constant. For example, you could use preprocessor conditionals to select the appropriate cache attribute based on the target architecture.

Suggested change

.size = ALIGN_UP(entry->size, CONFIG_MM_DRV_PAGE_SIZE),

.attr = K_MEM_PARTITION_P_RO_U_RO | XTENSA_MMU_CACHED_WB,

.size = ALIGN_UP(entry->size, CONFIG_MM_DRV_PAGE_SIZE),

#ifdef XTENSA_MMU_CACHED_WB

.attr = K_MEM_PARTITION_P_RO_U_RO | XTENSA_MMU_CACHED_WB,

#else

.attr = K_MEM_PARTITION_P_RO_U_RO,

#endif

Copilot · 2026-02-05T14:08:47Z

zephyr/lib/fast-get.c

+		int err = fast_get_access_grant(entry->thread, ret, size);
+
+		if (err < 0) {
+			sof_heap_free(NULL, ret);


When fast_get_access_grant fails, the allocated memory is freed and ret is set to NULL, but the entry fields (entry->size, entry->sram_ptr, entry->dram_ptr set at line 224) remain set. This leaves the entry in an inconsistent state. Consider resetting the entry with memset(entry, 0, sizeof(*entry)) after freeing the memory to ensure clean error handling, similar to what's done in fast_put at line 278.

Suggested change

sof_heap_free(NULL, ret);

sof_heap_free(NULL, ret);

memset(entry, 0, sizeof(*entry));

zephyr/lib/fast-get.c

Copilot · 2026-02-05T14:08:48Z

zephyr/lib/fast-get.c


-	ret = sof_heap_alloc(heap, SOF_MEM_FLAG_USER, size, PLATFORM_DCACHE_ALIGN);
+	/*
+	 * If a userspace threads is the first user to fast-get the buffer, an


The word "threads" should be "thread" (singular) to match the grammatical context of the sentence.

Suggested change

* If a userspace threads is the first user to fast-get the buffer, an

* If a userspace thread is the first user to fast-get the buffer, an

zephyr/lib/fast-get.c

Fix "unused function" Zephyr compilation warnings. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>

softwarecki · 2026-02-05T15:01:57Z

zephyr/lib/fast-get.c

+#define LOG_DBG(...) do {} while (0)
+#define LOG_INF(...) do {} while (0)
+#define LOG_WRN(...) do {} while (0)
+#define LOG_ERR(...) do {} while (0)


As I understand, these are Zephyr macros. I suspect they might be used in other places soon. Do we want to move this else into a separate file that is included when Zephyr is not present?

@lyakh Also wondering why do we need to ifdef Zephyr, this is zephyr/lib/fast-get.c after all?

here's why: https://github.com/thesofproject/sof/actions/runs/21723932524/job/62660874849?pr=10525

Ugh, that's not good. cmocka has no business to use Zephyr adaption code. Can you add a note that this special handling is only needed for "sof/test/cmocka/src/lib/fast-get/fast-get-tests.c". We need @jsarha to check this out, doesn't have to be done in this PR. This should probably moved into a ztest (and not in cmocka).

@kv2019i these tests have already been ported and after verifying that I didn't introduce regression in the code coverage area, I wanted to remove the cmock version. @lgirdwood stated that they must remain to be able to test them with valgrind and I backed out of removing them (the discussion can be found here #10367). Ultimately I want to remove them after I introduce a build with address sanitizer to the ztest version. The sanitizer can detect the same and more errors than valgrind, so it would be an improvement.

Zephyr is always TRUE. No other RTOS is supported now. The Mocks can define these as needed into printf.

kv2019i

Check the comment in second patch.

kv2019i · 2026-02-05T17:31:29Z

zephyr/lib/fast-get.c

+#define LOG_DBG(...) do {} while (0)
+#define LOG_INF(...) do {} while (0)
+#define LOG_WRN(...) do {} while (0)
+#define LOG_ERR(...) do {} while (0)


@lyakh Also wondering why do we need to ifdef Zephyr, this is zephyr/lib/fast-get.c after all?

tmleman · 2026-02-06T13:33:32Z

app/boards/intel_adsp_ace15_mtpm.conf

 CONFIG_SYS_CLOCK_TICKS_PER_SEC=12000
+CONFIG_ACE_V1X_RTC_COUNTER=n



I think that commit can be dropped after this PR is merged: #10529

#10529 now merged

lyakh added 2 commits February 5, 2026 14:50

Copilot AI review requested due to automatic review settings February 5, 2026 13:59

lyakh requested review from abonislawski, dbaluta, iuliana-prodan, jxstelter, kv2019i, lbetlej, lgirdwood, mmaka1, plbossart and ranj063 as code owners February 5, 2026 13:59

Copilot started reviewing on behalf of lyakh February 5, 2026 14:02 View session

Copilot AI reviewed Feb 5, 2026

View reviewed changes

intel_adsp: ace: fix compiler warnings

e521410

Fix "unused function" Zephyr compilation warnings. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>

lyakh force-pushed the fastget branch from 6dd7ba2 to e521410 Compare February 5, 2026 14:29

softwarecki requested review from softwarecki February 5, 2026 14:56

softwarecki reviewed Feb 5, 2026

View reviewed changes

kv2019i reviewed Feb 5, 2026

View reviewed changes

tmleman reviewed Feb 6, 2026

View reviewed changes

		.size = ALIGN_UP(entry->size, CONFIG_MM_DRV_PAGE_SIZE),
		.attr = K_MEM_PARTITION_P_RO_U_RO \| XTENSA_MMU_CACHED_WB,

	sof_heap_free(NULL, ret);
	sof_heap_free(NULL, ret);
	memset(entry, 0, sizeof(*entry));

	* If a userspace threads is the first user to fast-get the buffer, an
	* If a userspace thread is the first user to fast-get the buffer, an

		CONFIG_SYS_CLOCK_TICKS_PER_SEC=12000
		CONFIG_ACE_V1X_RTC_COUNTER=n

Conversation

lyakh commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Feb 5, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 5, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Copilot AI Feb 5, 2026

Choose a reason for hiding this comment

Uh oh!

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!

kv2019i 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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

lyakh commented Feb 5, 2026 •

edited

Loading