linux.git/sound/soc/sof, branch v6.18

Merge tag 'asoc-fix-v6.18-merge-window' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

2025-10-08T11:52:14+00:00

ASoC: Fixes for v6.18

A small pile of fixes, almost all for the Intel and SOF code surrounding
management of the host buffer.  We've also got one fix for Meson and new
device IDs and quirk supporting the RT722VB.

ASoC: SOF: Intel: Read the LLP via the associated Link DMA channel

2025-10-03T11:39:48+00:00

It is allowed to mix Link and Host DMA channels in a way that their index
is different. In this case we would read the LLP from a channel which is
not used or used for other operation.

Such case can be reproduced on cAVS2.5 or ACE1 platforms with soundwire
configuration:
playback to SDW would take Host channel 0 (stream_tag 1) and no Link DMA
used
Second playback to HDMI (HDA) would use Host channel 1 (stream_tag 2) and
Link channel 0 (stream_tag 1).

In this case reading the LLP from channel 2 is incorrect as that is not the
Link channel used for the HDMI playback.

To correct this, we should look up the BE and get the channel used on the
Link side.

Fixes: 67b182bea08a ("ASoC: SOF: Intel: hda: Implement get_stream_position (Linear Link Position)")
Signed-off-by: Peter Ujfalusi 
Reviewed-by: Kai Vehmanen 
Reviewed-by: Ranjani Sridharan 
Link: https://patch.msgid.link/20251002074719.2084-6-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: ipc4-pcm: do not report invalid delay values

2025-10-03T11:39:48+00:00

Add a sanity check for the calculated delay value before reporting it to
the application. If the value is clearly invalid, emit a rate limited
warning to kernel log and return a zero delay. This can occur e.g if the
host or link DMA hits a buffer over/underrun condition.

Signed-off-by: Kai Vehmanen 
Reviewed-by: Péter Ujfalusi 
Reviewed-by: Bard Liao 
Signed-off-by: Peter Ujfalusi 
Link: https://patch.msgid.link/20251002074719.2084-5-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: sof-audio: add dev_dbg_ratelimited wrapper

2025-10-03T11:39:47+00:00

Add dev_dbg_ratelimited() wrapper for snd_sof_pcm specific debug prints
that needs rate limited.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Kai Vehmanen 
Reviewed-by: Bard Liao 
Link: https://patch.msgid.link/20251002074719.2084-4-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: ipc4/Intel: Fix the host buffer

2025-10-02T17:07:06+00:00

Merge series from Peter Ujfalusi :

The size of the DSP host buffer was incorrectly defined as 2ms while
it is 4ms and the ChainDMA PCMs are using 5ms as host facing buffer.

The constraint will be set against the period time rather than the buffer
time to make sure that application will not face with xruns when the
DMA bursts to refill the host buffer.

The minimal period size will be also used by Pipewire in case of SOF
cards to set the headroom to a length which will avoid the cases when
the hw_ptr jumps over the appl_ptr because of a burst.
Iow, it will make Pipewire to keep a safe distance from the hw_ptr.

https://github.com/thesofproject/linux/issues/5284
https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/740
https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/2548

ASoC: SOF: Intel: hda-pcm: Place the constraint on period time instead of buffer time

2025-10-02T14:03:32+00:00

Instead of constraining the ALSA buffer time to be double of the firmware
host buffer size, it is better to set it for the period time.
This will implicitly constrain the buffer time to a safe value
(num_periods is at least 2) and prohibits applications to set smaller
period size than what will be covered by the initial DMA burst.

Fixes: fe76d2e75a6d ("ASoC: SOF: Intel: hda-pcm: Use dsp_max_burst_size_in_ms to place constraint")
Signed-off-by: Peter Ujfalusi 
Reviewed-by: Ranjani Sridharan 
Reviewed-by: Kai Vehmanen 
Reviewed-by: Bard Liao 
Link: https://patch.msgid.link/20251002135752.2430-4-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: ipc4-topology: Account for different ChainDMA host buffer size

2025-10-02T14:03:31+00:00

For ChainDMA the firmware allocates 5ms host buffer instead of the standard
4ms which should be taken into account when setting the constraint on the
buffer size.

Fixes: 842bb8b62cc6 ("ASoC: SOF: ipc4-topology: Save the DMA maximum burst size for PCMs")
Signed-off-by: Peter Ujfalusi 
Reviewed-by: Ranjani Sridharan 
Reviewed-by: Kai Vehmanen 
Reviewed-by: Bard Liao 
Link: https://patch.msgid.link/20251002135752.2430-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: ipc4-topology: Correct the minimum host DMA buffer size

2025-10-02T14:03:30+00:00

The firmware has changed the minimum host buffer size from 2 periods to
4 periods (1 period is 1ms) which was missed by the kernel side.

Adjust the SOF_IPC4_MIN_DMA_BUFFER_SIZE to 4 ms to align with firmware.

Link: https://github.com/thesofproject/sof/commit/f0a14a3f410735db18a79eb7a5f40dc49fdee7a7
Fixes: 594c1bb9ff73 ("ASoC: SOF: ipc4-topology: Do not parse the DMA_BUFFER_SIZE token")
Signed-off-by: Peter Ujfalusi 
Reviewed-by: Ranjani Sridharan 
Reviewed-by: Kai Vehmanen 
Reviewed-by: Bard Liao 
Link: https://patch.msgid.link/20251002135752.2430-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: ipc4-pcm: fix start offset calculation for chain DMA

2025-10-02T12:31:44+00:00

Assumption that chain DMA module starts the link DMA when 1ms of
data is available from host is not correct. Instead the firmware
chain DMA module fills the link DMA with initial buffer of zeroes
and the host and link DMAs are started at the same time.

This results in a small error in delay calculation. This can become a
more severe problem if host DMA has delays that exceed 1ms. This results
in negative delay to be calculated and bogus values reported to
applications. This can confuse some applications like
alsa_conformance_test.

Fix the issue by correctly calculating the firmware chain DMA
preamble size and initializing the start offset to this value.

Cc: stable@vger.kernel.org
Fixes: a1d203d390e0 ("ASoC: SOF: ipc4-pcm: Enable delay reporting for ChainDMA streams")
Signed-off-by: Kai Vehmanen 
Reviewed-by: Péter Ujfalusi 
Reviewed-by: Bard Liao 
Signed-off-by: Peter Ujfalusi 
Link: https://patch.msgid.link/20251002074719.2084-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: ipc4-pcm: fix delay calculation when DSP resamples

2025-10-02T12:31:43+00:00

When the sampling rates going in (host) and out (dai) from the DSP
are different, the IPC4 delay reporting does not work correctly.
Add support for this case by scaling the all raw position values to
a common timebase before calculating real-time delay for the PCM.

Cc: stable@vger.kernel.org
Fixes: 0ea06680dfcb ("ASoC: SOF: ipc4-pcm: Correct the delay calculation")
Signed-off-by: Kai Vehmanen 
Reviewed-by: Péter Ujfalusi 
Reviewed-by: Bard Liao 
Signed-off-by: Peter Ujfalusi 
Link: https://patch.msgid.link/20251002074719.2084-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown