linux-next.git/sound/soc/sof/intel, branch master

Merge remote-tracking branch 'asoc/for-7.3' into asoc-next

2026-08-03T12:18:29+00:00

ASoC: SOF: Intel: hda: Avoid ACE2+ link DMA stream allocation hazards

2026-07-31T19:57:16+00:00

On ACE2+ platforms the link DMA stream allocator must avoid two hardware errata in mlink-capable systems: - Concurrent (cross-direction) hazard: when SoundWire shares a physical link DMA stream index with HDaudio, iDisp or UAOL across the two directions, the LLP and timestamp values for the affected stream are wrong. SSP and DMIC are not affected because every DMA request from those links carries one sample block. - Sequential (playback only) hazard: once a HDaudio or iDisp link has used a playback stream index, that index cannot drive any non HDA/iDisp link in the same direction until the next controller reset (CRST#). Track the active link type per direction in two masks (one for SoundWire, one for HDA/iDisp/UAOL) and the persistent set of playback stream indices touched by HDA/iDisp in a third mask. The link DMA allocator skips streams that would violate either rule. Streams are released from the active masks when the stream is released; all masks are cleared in hda_dsp_ctrl_init_chip() because the CRST# performed there clears the hardware state as well. A new helper hda_bus_ml_link_get_type() returns the link type from the existing extended link descriptor so the SOF allocator can tell SoundWire, HDA/iDisp and UAOL apart without duplicating the parsing. The implementation is generic. On platforms older than ACE2 every link is reported as HDA, only the sequential mask is ever set and it has no effect because no other link types are present, so behavior is unchanged. Signed-off-by: Peter Ujfalusi Reviewed-by: Kai Vehmanen Reviewed-by: Bard Liao Reviewed-by: Liam Girdwood Link: https://patch.msgid.link/20260730125130.29887-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel: hda: Remove unused hda_bus_ml_put_all()

2026-07-31T19:57:09+00:00

The helper became unused after probe no longer drops all non-alt links, so remove the dead API and implementation. Signed-off-by: Peter Ujfalusi Reviewed-by: Kai Vehmanen Reviewed-by: Bard Liao Reviewed-by: Liam Girdwood Link: https://patch.msgid.link/20260730125130.29887-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel: hda: Keep non-alt mlinks powered at probe on ACE2+

2026-07-31T19:57:07+00:00

Drop the hda_bus_ml_put_all() call at the end of hda_init_caps(). On multi-link (mlink) capable platforms the non-alternate links (HDaudio and iDisp) are powered on by hardware when CRST# is de-asserted (LCTL.SPA = 1) and their ref_count is pre-charged to 1 in hda_ml_alloc_h2link() to match this state. The put_all call immediately dropped that reference and toggled LCTL.SPA back to 0, relying on the first stream open to power the link up again. On ACE2+ platforms this redundant SPA 1->0->1 toggle at probe leaves the Processing Pipe Capability (PPLC) Linear Link Position counters in a state where they do not advance on the first stream after boot. The counters only start working after the first full runtime suspend/resume cycle, which includes a CRST# assert/deassert that fully resets the PPC AON block. Keep the non-alt links powered from CRST# de-assert through first use. System suspend still powers them down via hda_bus_ml_suspend(), and resume relies on CRST# de-assert to bring them back up, so no other path is affected. Signed-off-by: Peter Ujfalusi Reviewed-by: Kai Vehmanen Reviewed-by: Bard Liao Reviewed-by: Liam Girdwood Link: https://patch.msgid.link/20260730125130.29887-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel: hda: Fold mlink enumeration into hda_dsp_ctrl_init_chip()

2026-07-31T19:57:06+00:00

Move the hda_bus_ml_init() call from hda_init_caps() into hda_dsp_ctrl_init_chip(), right after the HDA controller reset has been de-asserted and unsolicited responses have been accepted. hda_dsp_ctrl_init_chip() already calls hda_bus_ml_reset_losidv() at the end of its sequence to clear the stream-to-link mapping. On first boot this call was a no-op because the multi-link list had not yet been populated: hda_bus_ml_init() only runs later in hda_init_caps(). Enumerating the links inside init_chip() makes the LOSIDV reset effective on first boot as well, without adding a second reset call from the probe path. hda_bus_ml_init() now returns early when the hlink_list is already populated, so the subsequent invocations from the D3 resume path (hda_resume() -> hda_dsp_ctrl_init_chip(false)) are no-ops. Signed-off-by: Peter Ujfalusi Reviewed-by: Kai Vehmanen Reviewed-by: Bard Liao Reviewed-by: Liam Girdwood Link: https://patch.msgid.link/20260730125130.29887-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel: hda/mtl: Handle powered on DSP on boot

2026-07-31T19:32:27+00:00

Peter Ujfalusi says: It is expected that the DSP is in power down state when the firmware boot is attempted. If the DSP for any reason was left powered up then the DSP boot will fail since the ROM boot sequence might not be able to run. Make sure that the DSP is off before proceeding to boot it up. We have seen reports that for some undetermined reasons the DSP was on during system boot and this caused firmware boot failure as the DSP cannot be booted up - it was already in booted up state. Link: https://patch.msgid.link/20260730122857.5294-1-peter.ujfalusi@linux.intel.com

ASoC: SOF: Intel: mtl: Power down DSP if it is left enabled in pre_fw_run()

2026-07-31T19:32:25+00:00

It is expected that the DSP is in power down state when the firmware boot is attempted. If the DSP for any reason was left powered up then the DSP boot will fail since the ROM boot sequence might not be able to run. Make sure that the DSP is off before proceeding to boot it up. Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Reviewed-by: Liam Girdwood Link: https://patch.msgid.link/20260730122857.5294-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel: hda: Power down DSP if it is left enabled in pre_fw_run()

2026-07-31T19:32:24+00:00

It is expected that the DSP is in power down state when the firmware boot is attempted. If the DSP for any reason was left powered up then the DSP boot will fail since the ROM boot sequence might not be able to run. Make sure that the DSP is off before proceeding to boot it up. Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Reviewed-by: Liam Girdwood Link: https://patch.msgid.link/20260730122857.5294-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel: hda-stream: clear hstream->running flag in hw_params

2026-07-31T15:46:06+00:00

During hw_params call we make sure that the host DMA is stopped but the hstream->running flag is not explicitly cleared at the same time. If the host DMA fails to stop during previous use then the flag is left set and on next start the host DMA will be left disabled since the trigger:STOP will skip the DMA enable. Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Link: https://patch.msgid.link/20260730122241.30541-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC/soundwire: Intel: reset the PCMSyCM registers in hda_sdw_bpt_close

2026-07-31T12:23:10+00:00

Resetting the PCMSyCM registers is required for Intel SoundWire stream. The same procedure is done in sdw_hda_dai_hw_params() for the normal SoundWire stream, too. Signed-off-by: Bard Liao Reviewed-by: Péter Ujfalusi Reviewed-by: Liam Girdwood Reviewed-by: Pierre-Louis Bossart Acked-by: Vinod Koul Link: https://patch.msgid.link/20260730012518.2180906-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown