audio: kpb: add a Zephyr-native notification mechanism

[lyakh]

KPB currently can use SOF notifications and AMS for triggering, but neither of them is currently accessible from userspace. Use a Zephyr native queue API instead.

[Copilot]

Copilot review overview

🟡 Changes recommended

Unresolved critical build and notification-path issues, plus lifecycle and syscall-access defects, block approval.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 3 · 1

Open (4)

• KPB queue option enables Zephyr-only code in non-Zephyr builds · New
• Global queue and thread state breaks multiple KPB instances · New
• Queue mode disconnects existing KPB event producers · New
• Public notifier APIs lack lifetime and usage contracts · New

What changed in this PR

Adds a Zephyr-native queue-based notification mechanism for KPB userspace clients.

Changes:

• Registers generated KPB syscall headers.
• Adds notifier APIs, queue state, and worker-thread handling.
• Adds and enables the KPB_CLI_Q configuration option.

File	Summary
zephyr/​CMakeLists.txt	Registers KPB syscall headers.
src/​include/​sof/​audio/​kpb.h	Adds queue state and notifier API declarations.
src/​audio/​kpb.c	Implements queue processing, syscalls, and lifecycle management.
src/​audio/​Kconfig	Adds and enables queue-based KPB configuration.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[lyakh]

hm, I was assuming that multiple KPB instances don't make sense, but maybe I was wrong. Let me fix that.

[lyakh]

alright, checked that: currently neither the notifier nor the AMS version support multiple KPB instances. The notifier version only supports a single handler per type (as in NOTIFIER_ID_KPB_CLIENT_EVT), and AMS could support routing to multiple handlers in principle, but current clients don't support it either: e.g.

sof/src/samples/audio/detect_test.c

Line 163 in b6c6a05

cd->client_data.id = 0; /**< TODO: acquire proper id from kpb */

[lgirdwood]

@lyakh does the client Q support multiple cores and memory domains ?

[lyakh]

@lyakh does the client Q support multiple cores and memory domains ?

@lgirdwood the API adds 2 functions: kpb_notifier_init() which is a syscall, running in the context of the caller thread respectively on the same core and does two things: initialises caller's object and grants the caller access to the global KPB queue - regardless of the core; and kpb_notifier_schedule() which just calls a standard Zephyr data queuing function, which wakes up the waiting thread or adds data to the queue - and that should work across cores too. So, I don't see any restrictions in those areas.