ipc4: notification: Add filtering feature by wjablon1 · Pull Request #10552 · thesofproject/sof

wjablon1 · 2026-02-17T09:51:08Z

Adding a handler for retrieving info about the IPC4 notification mask out
of the LargeConfig. The notification mask is then used for filtering IPC4
notifications sent by the FW.

This feature allows muting notifications of a given kind to enhance
readability of logs during debugging. Also, this feature enhances
reliability of certain tests run on FPGA-based setups where the FW
notifications are too overwhelming for those setups.

Moving memory allocation for IPC4 notifications to the notification module. With this change all the logic needed for sending IPC4 notifications is contained within the notification module. Currently all the notifications are allocated out of the same memory pool, so the selection of a memory pool is not part of the function interface of the notification module, but we can easily modify that behavior by adding a pool ID parameter. This change enables robust implementation of the notification filtering feature without exposing additional symbols to LLEXT modules. Signed-off-by: Wojciech Jablonski <wojciech.jablonski@intel.com>

Adding a handler for retrieving info about the IPC4 notification mask out of the LargeConfig. The notification mask is then used for filtering IPC4 notifications sent by the FW. This feature allows muting notifications of a given kind to enhance readability of logs during debugging. Also, this feature enhances reliability of certain tests run on FPGA-based setups where the FW notifications are too overwhelming for those setups. Signed-off-by: Wojciech Jablonski <wojciech.jablonski@intel.com>

lyakh · 2026-02-18T08:09:27Z

src/audio/chain_dma.c

-			cd->xrun_notification_sent = true;
-		}
+		uint32_t node_id = cd->link_connector_node_id.dw;
+		bool notif_sent = false;


superfluous initialisation

lyakh · 2026-02-18T08:09:43Z

src/audio/dai-zephyr.c

 	if (ret == -EPIPE && !dd->xrun_notification_sent) {
-		struct ipc_msg *notify = ipc_notification_pool_get(IPC4_RESOURCE_EVENT_SIZE);
+		uint32_t ppl_id = dev->pipeline->pipeline_id;
+		bool notif_sent = false;


lyakh · 2026-02-18T08:10:11Z

src/audio/host-zephyr.c

-			hd->xrun_notification_sent = true;
-		}
+		uint32_t ppl_id = dev->pipeline->pipeline_id;
+		bool notif_sent = false;


lyakh · 2026-02-18T08:12:59Z

src/ipc/ipc4/notification.c

+	if (!msg)
+		return false;
+
+	struct ipc4_resource_event_data_notification *notif = msg->tx_data;


I assume this cannot be NULL

yes, the payload is allocated along with the msg as a single rzalloc operation.

lyakh · 2026-02-18T08:17:00Z

src/ipc/ipc4/notification.c

+	mixer_underrun_data.data_mixed = data_mixed;
+	mixer_underrun_data.expected_data_mixed = expected_data_mixed;
+
+	send_resource_notif(resource_id, SOF_IPC4_MIXER_UNDERRUN_DETECTED, SOF_IPC4_PIPELINE,


how about we only export send_resource_notif() and move all this component-specific functions to respective components and potentially make them static there?

There are pros and cons. Function send_resource_notif takes numerous arguments. If we keep it static, we give the compile a chance to optimize them.

On the other hand, your idea would allow us to move the "if (cd->stream_direction)" condition into a single static function that determines the right arguments to send_resource_notif instead of having to choose the right function based on the condition.

Its a tough call and I didn't think about this. My focus was to allow efficient implantation of the notification mask without making the existing code too cumbersome.

Also some middle ground approach is possible. For example we can merge send_gateway_underrun_notif_msg and send_gateway_overrun_notif_msg into a single function send_gateway_xrun_notif_msg but still keep it in the notification module.

This approach would eliminate the repetition of the following code in dai-zephyr.c and host-zephyr.c

if (dev->direction == SOF_IPC_STREAM_PLAYBACK) notif_sent = send_copier_gateway_underrun_notif_msg(ppl_id); else notif_sent = send_copier_gateway_overrun_notif_msg(ppl_id);

lyakh · 2026-02-18T08:19:05Z

src/audio/base_fw.c


+__cold static int basefw_notification_mask_info(const char *data)
+{
+	struct ipc4_notification_mask_info *mask_info;


we could make the argument const void *data and just initialise struct ipc4_notification_mask_info *mask_info = data; directly here

you are right. I just used a similar function as a template ;)

kv2019i

Looks good, no blockers.

lgirdwood

@wjablon1 we may have a mix of kernel and user space clients sending IPC4 notifications, I assume this is being catered for here ?
LGTM.

wjablon1 · 2026-02-18T15:58:56Z

@lgirdwood The goal is to enhance IPC4 compatibility to be able to re-use test scenarios for the SOF target (so yes, this is for a user-space test client). As I mention in the description, some test scenarios have the IPC notifications turned off due to reliability issues(poor performance on FPGA setups). Consequently, just because a single step is unsupported, the entire test scenario ends up with failure.

The general goal is to turn our regression "green". We tend to disable selected tests for SOF target if an unsupported functionality it too heavy to implement and/or it is completely useless. But for lightweight and potentially useful features like this one, we typically lean towards adding a SOF implementation.

wjablon1 · 2026-02-18T16:04:55Z

Also, for this specific feature I found a TODO in the in the base_fw:

/* TODO: add more support */
case IPC4_DSP_RESOURCE_STATE:
case IPC4_NOTIFICATION_MASK:

(btw. I probably need to sort that out as well)

tmleman · 2026-02-18T17:29:55Z

src/ipc/ipc4/notification.c

+	memset(&notif->event_data, 0, sizeof(notif->event_data));
+	if (data && data_size)
+		memcpy_s(&notif->event_data, sizeof(notif->event_data), data, data_size);
+


Since you are using memcpy_s(), you should check the return value and avoid sending the IPC notification if the copy fails by returning false. This prevents sending potentially corrupted data.

tmleman · 2026-02-18T17:46:13Z

src/include/ipc4/notification.h

-void process_data_error_notif_msg_init(struct ipc_msg *msg, uint32_t resource_id,
-				       uint32_t error_code);
+void send_process_data_error_notif_msg(uint32_t resource_id, uint32_t error_code);

-void copier_gateway_underrun_notif_msg_init(struct ipc_msg *msg, uint32_t pipeline_id);
-void copier_gateway_overrun_notif_msg_init(struct ipc_msg *msg, uint32_t pipeline_id);
-void gateway_underrun_notif_msg_init(struct ipc_msg *msg, uint32_t resource_id);
-void gateway_overrun_notif_msg_init(struct ipc_msg *msg, uint32_t resource_id);
+bool send_copier_gateway_underrun_notif_msg(uint32_t pipeline_id);
+bool send_copier_gateway_overrun_notif_msg(uint32_t pipeline_id);
+bool send_gateway_underrun_notif_msg(uint32_t resource_id);
+bool send_gateway_overrun_notif_msg(uint32_t resource_id);

-void mixer_underrun_notif_msg_init(struct ipc_msg *msg, uint32_t resource_id, uint32_t eos_flag,
-				   uint32_t data_mixed, uint32_t expected_data_mixed);
+void send_mixer_underrun_notif_msg(uint32_t resource_id, uint32_t eos_flag, uint32_t data_mixed,
+				   uint32_t expected_data_mixed);


nit: A consistent interface would probably be better, either we return true when notification has been sent or we return nothing.

wjablon1 requested review from RanderWang, bardliao, dbaluta, kv2019i, lbetlej, lgirdwood, marcinszkudlinski, mmaka1, pblaszko and plbossart as code owners February 17, 2026 09:51

wjablon1 changed the title ~~Notif mask~~ ipc4: notification: Add filtering feature Feb 17, 2026

wjablon1 requested review from abonislawski, serhiy-katsyuba-intel, softwarecki and tmleman February 17, 2026 09:53

wjablon1 added 2 commits February 17, 2026 11:21

wjablon1 force-pushed the notif_mask branch from 8029453 to b9ebeb7 Compare February 17, 2026 10:29

lyakh reviewed Feb 18, 2026

View reviewed changes

kv2019i reviewed Feb 18, 2026

View reviewed changes

lgirdwood reviewed Feb 18, 2026

View reviewed changes

tmleman reviewed Feb 18, 2026

View reviewed changes

Conversation

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

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!

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!

lgirdwood left a comment

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Uh oh!

wjablon1 commented Feb 18, 2026

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

Comments

wjablon1 commented Feb 17, 2026 •

edited

Loading

wjablon1 commented Feb 18, 2026 •

edited

Loading