ipc4: add counter to mtrace buffer status notification

[ujfalusi]

Increment a dedicated counter on each
SOF_IPC4_NOTIFY_LOG_BUFFER_STATUS notification and place the current value in the IPC extension field, so the host side can distinguish consecutive mtrace notifications.

[Copilot]

Pull request overview

This PR adds a counter mechanism to mtrace buffer status notifications to help the host distinguish between consecutive notifications. Each time a SOF_IPC4_NOTIFY_LOG_BUFFER_STATUS notification is sent, a counter is incremented and its value is placed in the IPC extension field.

Changes:

• Introduced an atomic counter for tracking mtrace notifications
• Modified notification logic to increment and include counter value in extension field

---

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

[Copilot]

The atomic counter should be initialized explicitly to ensure a known starting state. Consider using ATOMIC_INIT(0) or an initialization function to set the initial value to 0.

Suggested change

	static atomic_t mtrace_notify_counter;
	static atomic_t mtrace_notify_counter = ATOMIC_INIT(0);

[Copilot]

Using separate atomic_add() and atomic_read() operations creates a potential race condition. Between these two operations, another thread could modify the counter, causing the extension field to contain a different value than what was incremented. Use atomic_inc_return() or atomic_fetch_add() instead to atomically increment and read the value in a single operation.

Suggested change

	atomic_add(&mtrace_notify_counter, 1);
	msg_notify.extension = atomic_read(&mtrace_notify_counter);
	msg_notify.extension = atomic_inc_return(&mtrace_notify_counter);

[lgirdwood]

ack atomic_add() will return the current value which we should use in the extension.

[lgirdwood]

ack atomic_add() will return the current value which we should use in the extension.

[tmleman]

Blocking until doubts are clarified.

[tmleman]

Why does the host need this? Has there been a situation where it received the same notification more than once?
I checked the documentation and there is no such iterator in this message. I think in the case of all notifications the extension field remains empty.