user/sven/linux.git/include/sound, branch v6.6.67

ALSA: usb-audio: Update UMP group attributes for GTB blocks, too

2024-12-14T19:00:23Z

commit ebaa86c0bddd2c47c516bf2096b17c0bed71d914 upstream. When a FB is created from a GTB instead of UMP FB Info inquiry, we missed the update of the corresponding UMP Group attributes. Export the call of updater and let it be called from the USB driver. Fixes: 0642a3c5cacc ("ALSA: ump: Update substream name from assigned FB names") Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20240807092303.1935-5-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman

ALSA: ump: Update substream name from assigned FB names

2024-12-14T18:59:48Z

[ Upstream commit 0642a3c5cacc0321c755d45ae48f2c84475469a6 ] We had a nice name scheme in ALSA sequencer UMP binding for each sequencer port referring to each assigned Function Block name, while the legacy rawmidi refers only to the UMP Endpoint name. It's better to align both. This patch moves the UMP Group attribute update functions into the core UMP code from the sequencer binding code, and improve the substream name of the legacy rawmidi. Link: https://patch.msgid.link/20240729141315.18253-1-tiwai@suse.de Signed-off-by: Takashi Iwai Stable-dep-of: aaa55faa2495 ("ALSA: seq: ump: Fix seq port updates per FB info notify") Signed-off-by: Sasha Levin

ASoC: tas2781: mark dvc_tlv with __maybe_unused

2024-10-17T13:24:11Z

[ Upstream commit 831ec5e3538e989c7995137b5c5c661991a09504 ] Since we put dvc_tlv static variable to a header file it's copied to each module that includes the header. But not all of them are actually used it. Fix this W=1 build warning: include/sound/tas2781-tlv.h:18:35: warning: 'dvc_tlv' defined but not used [-Wunused-const-variable=] Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202403290354.v0StnRpc-lkp@intel.com/ Fixes: ae065d0ce9e3 ("ALSA: hda/tas2781: remove digital gain kcontrol") Signed-off-by: Gergo Koteles Message-ID: <0e461545a2a6e9b6152985143e50526322e5f76b.1711665731.git.soyer@irl.hu> Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ASoC: cs35l56: Load tunings for the correct speaker models

2024-10-17T13:24:07Z

[ Upstream commit 245eeff18d7a37693815250ae15979ce98c3d190 ] If the "spk-id-gpios" property is present it points to GPIOs whose value must be used to select the correct bin file to match the speakers. Some manufacturers use multiple sources of speakers, which need different tunings for best performance. On these models the type of speaker fitted is indicated by the values of one or more GPIOs. The number formed by the GPIOs identifies the tuning required. The speaker ID must be used in combination with the subsystem ID (either from PCI SSID or cirrus,firmware-uid property), because the GPIOs can only indicate variants of a specific model. Signed-off-by: Richard Fitzgerald Fixes: 1a1c3d794ef6 ("ASoC: cs35l56: Use PCI SSID as the firmware UID") Link: https://msgid.link/r/20240129162737.497-14-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: tas2781-i2c: Drop weird GPIO code

2024-10-04T14:29:05Z

[ Upstream commit c2c0b67dca3cb3b3cea0dd60075a1c5ba77e2fcd ] The tas2781-i2c driver gets an IRQ from either ACPI or device tree, then proceeds to check if the IRQ has a corresponding GPIO and in case it does enforce the GPIO as input and set a label on it. This is abuse of the API: - First we cannot guarantee that the numberspaces of the GPIOs and the IRQs are the same, i.e that an IRQ number corresponds to a GPIO number like that. - Second, GPIO chips and IRQ chips should be treated as orthogonal APIs, the irqchip needs to ascertain that the backing GPIO line is set to input etc just using the irqchip. - Third it is using the legacy API which should not be used in new code yet this was added just a year ago. Delete the offending code. If this creates problems the GPIO and irqchip maintainers can help to fix the issues. It *should* not create any problems, because the irq isn't used anywhere in the driver, it's just obtained and then left unused. Fixes: ef3bcde75d06 ("ASoC: tas2781: Add tas2781 driver") Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20240807-asoc-tas-gpios-v2-1-bd0f2705d58b@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: tas2781: remove unused acpi_subysystem_id

2024-10-04T14:29:04Z

[ Upstream commit 4089d82e67a9967fc5bf2b4e5ef820d67fe73924 ] The acpi_subysystem_id is only written and freed, not read, so unnecessary. Signed-off-by: Gergo Koteles Link: https://lore.kernel.org/r/454639336be28d2b50343e9c8366a56b0975e31d.1707456753.git.soyer@irl.hu Signed-off-by: Mark Brown Stable-dep-of: c2c0b67dca3c ("ASoC: tas2781-i2c: Drop weird GPIO code") Signed-off-by: Sasha Levin

ALSA: ump: Transmit RPN/NRPN message at each MSB/LSB data reception

2024-09-08T05:54:30Z

[ Upstream commit e6ce8a28c768dbbad3f818db286cd0f4c7a921a8 ] The UMP 1.1 spec says that an RPN/NRPN should be sent when one of the following occurs: * a CC 38 is received * a subsequent CC 6 is received * a CC 98, 99, 100, and 101 is received, indicating the last RPN/NRPN message has ended and a new one has started That said, we should send a partial data even if it's not fully filled. Let's change the UMP conversion helper code to follow that rule. Link: https://patch.msgid.link/20240731130528.12600-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

ASoc: tas2781: Enable RCA-based playback without DSP firmware download

2024-08-03T06:53:57Z

[ Upstream commit 9f774c757e3fb2ac32dc4377e8f21f3364a8df81 ] In only loading RCA (Reconfigurable Architecture) binary case, no DSP program will be working inside tas2563/tas2781, that is dsp-bypass mode, do not support speaker protection, or audio acoustic algorithms in this mode. Fixes: ef3bcde75d06 ("ASoC: tas2781: Add tas2781 driver") Signed-off-by: Shenghao Ding Reviewed-by: Pierre-Louis Bossart Link: https://msgid.link/r/20240614133646.910-1-shenghao-ding@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ALSA: dmaengine: Synchronize dma channel after drop()

2024-07-25T07:50:49Z

[ Upstream commit e8343410ddf08fc36a9b9cc7c51a4e53a262d4c6 ] Sometimes the stream may be stopped due to XRUN events, in which case the userspace can call snd_pcm_drop() and snd_pcm_prepare() to stop and start the stream again. In these cases, we must wait for the DMA channel to synchronize before marking the stream as prepared for playback, as the DMA channel gets stopped by drop() without any synchronization. Make sure the ALSA core synchronizes the DMA channel by adding a sync_stop() hook. Reviewed-by: Peter Ujfalusi Signed-off-by: Jai Luthra Link: https://lore.kernel.org/r/20240611-asoc_next-v3-1-fcfd84b12164@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

ASoC: tas2781: Fix wrong loading calibrated data sequence

2024-06-12T09:12:47Z

[ Upstream commit b195acf5266d2dee4067f89345c3e6b88d925311 ] Calibrated data will be set to default after loading DSP config params, which will cause speaker protection work abnormally. Reload calibrated data after loading DSP config params. Remove declaration of unused API which load calibrated data in wrong sequence, changed the copyright year and correct file name in license header. Fixes: ef3bcde75d06 ("ASoC: tas2781: Add tas2781 driver") Signed-off-by: Shenghao Ding Link: https://msgid.link/r/20240518141546.1742-1-shenghao-ding@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin