kernel/linux.git/sound/soc/sof/ipc4.c, branch v7.0-rc7

ASoC: SOF: Use guard()/scoped_guard() for mutex locks where it makes sense

2026-01-12T11:21:24+00:00

Replace the manual mutex lock/unlock pairs with guard()/scoped_guard(). Only code refactoring, and no behavior change. Signed-off-by: Peter Ujfalusi Reviewed-by: Daniel Baluta Reviewed-by: Ranjani Sridharan Link: https://patch.msgid.link/20260112101004.7648-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipoc4: Support for generic bytes

2025-12-19T13:13:48+00:00

Merge series from Peter Ujfalusi : We support bytes control type for set and get, but these are module specific controls and there is no way to handle notifications from them in a generic way. Each control have module specific param_id and this param_id is only valid in the module's scope, other modules might use the same id for different functions for example. This series will add a new generic control type, similar to the existing ones for ENUM and SWITCH, which can be used to create bytes controls which can send notifications from firmware on change. The new param_id is 202 and the sof_ipc4_control_msg_payload is updated to describe bytes payload also. On set, the payload must include the sof_ipc4_control_msg_payload struct with the control's ID and data size, followed by the data. On get, the kernel needs to send the sof_ipc4_control_msg_payload struct along with the LARGE_CONFIG_GET message as payload with the ID of the control that needs to be retrieved. The raw data is received back without additional header. A notification might contain data, in this case the num_elems reflects the size in bytes, or without data. If no data is received then the control is marked as dirty and on read the kernel will refresh the data from firmware. The series includes mandatory fixes for existing code and adds support for sending payload with LARGE_CONFIG_GET when the param_id is either generic ENUM, SWITCH or BYTES control.

ASoC: SOF: ipc4: Add definition for generic bytes control

2025-12-17T16:35:50+00:00

Currently IPC4 only supports module specific custom bytes controls, where each control's param_id is module specific. These bytes controls cannot be handled in a generic way, there is no clean way to support for example notifications from firmware when their data has been changed. Add definition for generic bytes control which should be handled in a similar way as the enum/switch controls. The generic param id for BYTES is selected to be 202 Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-8-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc4: Support for sending payload along with LARGE_CONFIG_GET

2025-12-17T16:35:49+00:00

There are message types when we would need to send a payload along with the LARGE_CONFIG_GET message to provide information to the firmware on what data is requested. Such cases are the ALSA Kcontrol related messages when the high level param_id tells only the type of the control, but the ID/index of the exact control is specified in the payload area. The caller must place the payload for TX before calling the set_get_data() and this payload will be sent alongside with the message to the firmware. The data area will be overwritten by the received data from firmware. Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-7-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Add support for on-demand DSP boot

2025-12-15T14:07:41+00:00

On system suspend / resume we always power up the DSP and boot the firmware, which is not strictly needed as right after the firmware booted up we power the DSP down again on suspend and we also power it down after resume after some inactivity. Out of caution, add a new platform descriptor flag to enable on-demand DSP boot since this might not work without changes to platform code on certain platforms. With the on-demand dsp boot enabled we will not boot the DSP and firmware up on system or rpm resume, just enable audio subsystem since audio IPs, like HDA and SoundWire might be needed (codecs suspend/resume operation). Only boot up the DSP during the first hw_params() call when the DSP is really going to be needed. In this way we can handle the audio related use cases: normal audio use (rpm suspend/resume) system suspend/resume without active audio system suspend/resume with active audio system suspend/resume without active audio, and audio start before the rpm suspend timeout Add module option to force the on-demand DSP boot to allow it to be disabled or enabled without kernel change for testing. Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Reviewed-by: Liam Girdwood Link: https://patch.msgid.link/20251215132946.2155-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc4-pcm: Harmonize set pipeline state dbg

2025-06-20T10:33:05+00:00

Merge series from Peter Ujfalusi : The series harmonizes the debug prints for pipeline state changes. Currently we only print readable state change for single pipeline changes but when multiple pipeline's state is changed, it is omitted. Use human readable information in both cases in a harmonized way to aid debugging.

ASoC: SOF: ipc4: Add sof_ipc4_pipeline_state_str() for debugging

2025-06-19T12:19:53+00:00

Add sof_ipc4_pipeline_state_str() to translate enum sof_ipc4_pipeline_state into human readable form. Signed-off-by: Jyri Sarha Reviewed-by: Péter Ujfalusi Reviewed-by: Guennadi Liakhovetski Reviewed-by: Liam Girdwood Reviewed-by: Ranjani Sridharan Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20250619121121.25241-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc4/Intel: Add support for library restore firmware functionality

2025-06-19T12:19:35+00:00

The firmware will be able to only save and restore the context related to library management. This means that even without a full context save, the libraries do not need to be re-loaded to the firmware after second or consecutive boots. This is reported via the FW_READY notification, where BIT(15) indicates: 0 - the library restore is not done 1 - library restore is done This bit is only valid if full context save is not enabled, full context save is by definition saves and restores the library related book-keeping as well. Add a new flag to tell the platform code if the libraries have been restored, no need to reload them after boot. Signed-off-by: Peter Ujfalusi Reviewed-by: Guennadi Liakhovetski Reviewed-by: Liam Girdwood Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20250619105623.4546-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc4: Add support for Intel HW managed mic privacy messaging

2025-03-08T16:06:40+00:00

ACE3 (Panther Lake) introduced support for microphone privacy feature which can - in hardware - mute incoming audio data based on a state of a physical switch. The change in the privacy state is delivered through interface IP blocks and can only be handled by the link owner. In Intel platforms Soundwire is for example host owned, so the interrupt can only be handled by the host. Since the input stream is going to be muted by hardware, the host needs to send a message to firmware about the change in privacy so it can execute a fade out/in to enhance user experience. The support for microphone privacy can be queried from the HW_CONFIG data under the INTEL_MIC_PRIVACY_CAP tuple. This is Intel specific data, the core will pass it to platform code if the intel_configure_mic_privacy() callback is provided. Platform code can call sof_ipc4_mic_privacy_state_change() to send the IPC message to the firmware on state change. Signed-off-by: Peter Ujfalusi Reviewed-by: Ranjani Sridharan Reviewed-by: Liam Girdwood Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20250307112816.1495-6-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc4: Add support for split firmware releases

2025-02-06T16:28:02+00:00

A split SOF release consists of a base firmware and two libraries: -openmodules.ri for processing (audio) modules -debug.ri for debug and developer modules To handle this new release model add infrastructure to try to load the two library after boot optionally. This approach will allow flexibility on handling platforms in sof-bin with single or split configuration: single release: base firmware only split release: base firmware + openmodules + debug The files for the split firmware are located at the firmware directory. Signed-off-by: Peter Ujfalusi Reviewed-by: Guennadi Liakhovetski Reviewed-by: Kai Vehmanen Reviewed-by: Ranjani Sridharan Link: https://patch.msgid.link/20250206085237.19214-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown