kernel/git/stable/linux.git/sound/hda/hdac_stream.c, branch master

ALSA: hda: Move HD-audio core stuff into sound/hda/core

2025-07-11T07:55:36+00:00

This is a part of HD-audio code restructuring. Simply move the current code of sound/hda/* into the subdirectory sound/hda/core, so that more stuff can be moved into sound/hda cleanly later. Most of file names with hdac_ and hdac_ext_ prefix are renamed without the prefix, since they can be identified well in the directory name and superfluous. Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250709160434.1859-3-tiwai@suse.de

ALSA: hda: Remove unused snd_hdac_stream_get_spbmaxfifo

2025-05-08T09:50:21+00:00

snd_hdac_stream_get_spbmaxfifo() was originally added in 2015 in commit ee8bc4df1b5a ("ALSA: hdac: Add support to enable SPIB for hdac ext stream") when it was originally called snd_hdac_ext_stream_set_spbmaxfifo, it was renamed snd_hdac_ext_stream_get_spbmaxfifo shortly after and was finally renamed to snd_hdac_stream_get_spbmaxfifo in 2022. But it was never used. Remove it. Signed-off-by: Dr. David Alan Gilbert Link: https://patch.msgid.link/20250505011037.340592-1-linux@treblig.org Signed-off-by: Takashi Iwai

ALSA: hda: Transfer firmware in two chunks

2025-01-15T07:57:18+00:00

As per specification, SDxLVI shall be at least 1 i.e.: two chunks to perform a valid transfer. This is true for the PCM transfer code but not firmware-transfer one. Technical background: - the LVI > 0 rule shall be obeyed in PCM transfer - HW permits LVI == 0 when transfer is SW-controlled (SPIB) - FW download is not a PCM transfer and is SW-controlled (SPIB) The above is the fundament which AudioDSP firmware loading functions have been built upon and worked since 2016. The presented changes are to align the loading flows and avoid rising more questions in the future. Achieve the goal by splitting snd_hdac_stream_setup_periods() into substream-dependent and -independent part. Let snd_hdac_dsp_prepare() utilize the latter so that both DSP-loading and PCM flows utilize same BLDE setup loop which already takes care of cutting the buffer based on azx_dev->period_bytes. Signed-off-by: Cezary Rojewski Link: https://patch.msgid.link/20250114184239.120002-1-cezary.rojewski@intel.com Signed-off-by: Takashi Iwai

ALSA: hda: Add missing parameter description for snd_hdac_stream_timecounter_init()

2024-10-03T07:24:45+00:00

Add the missing description for the new parameter "start" of snd_hdac_stream_timecounter_init() in the previous patch. Fixes: df5215618fbe ("ALSA: hda: fix trigger_tstamp_latched") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202410031300.ecLmATNd-lkp@intel.com/ Link: https://patch.msgid.link/20241003072420.8932-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: hda: fix trigger_tstamp_latched

2024-10-02T10:50:24+00:00

When the trigger_tstamp_latched flag is set, the PCM core code assumes that the low-level driver handles the trigger timestamping itself. Ensure that runtime->trigger_tstamp is always updated. Buglink: https://github.com/alsa-project/alsa-lib/issues/387 Reported-by: Zeno Endemann Signed-off-by: Jaroslav Kysela Link: https://patch.msgid.link/20241002081306.1788405-1-perex@perex.cz Signed-off-by: Takashi Iwai

ALSA: hda: Downgrade BDL table overflow message

2024-02-21T10:14:16+00:00

When BDL table entry overflow happens, the driver spews an error message explicitly. But basically this condition can be triggered easily by an application and it may flood of error logs unnecessarily. Downgrade the error message with dev_dbg() as a debug message instead. Link: https://lore.kernel.org/r/20240221100607.6565-2-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: hda: Refer to correct stream index at loops

2023-11-21T15:42:06+00:00

In a couple of loops over the all streams, we check the bitmap against the loop counter. A more correct reference would be, however, the index of each stream, instead. This patch corrects the check of bitmaps to the stream index. Note that this change doesn't fix anything for now; all existing drivers set up the stream indices properly, hence the loop count is always equal with the stream index. That said, this change is only for consistency. Link: https://lore.kernel.org/r/20231121154125.4888-1-tiwai@suse.de Signed-off-by: Takashi Iwai

ALSA: hda: Add code_loading parameter to stream setup

2023-10-06T12:30:39+00:00

AudioDSP firmware is the one who kicks SDxFIFOS calculation when a stream is decoupled mode. During firmware bring up procedure, there is no firmware running and the code-loading stream is always a decoupled one. So, there is none to trigger the calculation and we end up with false-positive timeout (-110) messages. Signed-off-by: Cezary Rojewski Acked-by: Mark Brown Link: https://lore.kernel.org/r/20231006102857.749143-4-cezary.rojewski@intel.com Signed-off-by: Takashi Iwai

ALSA: hda: Fix stream fifo_size initialization

2023-10-06T12:30:19+00:00

SDxFIFOS register indicates the fifo size directly. There is no need to modify the value after reading the register. Signed-off-by: Cezary Rojewski Link: https://lore.kernel.org/r/20231006102857.749143-3-cezary.rojewski@intel.com Signed-off-by: Takashi Iwai

ALSA: hda: Fix possible null-ptr-deref when assigning a stream

2023-10-06T12:30:19+00:00

While AudioDSP drivers assign streams exclusively of HOST or LINK type, nothing blocks a user to attempt to assign a COUPLED stream. As supplied substream instance may be a stub, what is the case when code-loading, such scenario ends with null-ptr-deref. Signed-off-by: Cezary Rojewski Link: https://lore.kernel.org/r/20231006102857.749143-2-cezary.rojewski@intel.com Signed-off-by: Takashi Iwai