summaryrefslogtreecommitdiff
path: root/include/sound
AgeCommit message (Collapse)Author
2024-09-14Merge tag 'asoc-v6.12' of ↵Takashi Iwai
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next ASoC: Updates for v6.12 This is a very large set of changes, almost all in drivers rather than the core. Even with the addition of several quite large drivers the overall diffstat is negative thanks to the removal of some old Intel board support which has been obsoleted by the AVS driver, helped a bit by some factoring out into helpers (especially around the Soundwire machine drivers for x86). Highlights include: - More simplifications and cleanups throughout the subsystem from Morimoto-san. - Extensive cleanups and refactoring of the Soundwire drivers to make better use of helpers. - Removal of Intel machine support obsoleted by the AVS driver. - Lots of DT schema conversions. - Machine support for many AMD and Intel x86 platforms. - Support for AMD ACP 7.1, Mediatek MT6367 and MT8365, Realtek RTL1320 SoundWire and rev C, and Texas Instruments TAS2563
2024-09-13ASoC: tas2781: Add Calibration Kcontrols for ChromebookShenghao Ding
Add calibration related kcontrol for speaker impedance calibration and speaker leakage check for Chromebook. Signed-off-by: Shenghao Ding <shenghao-ding@ti.com> Link: https://patch.msgid.link/20240911232739.1509-1-shenghao-ding@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-09-13ASoC: sdw_utils/intel: move soundwire endpoint parsing helper functionsVijendar Mukunda
Move SoundWire endpoint parsing helper functions to common place holder. These functions will be used by other platform machine driver code. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://patch.msgid.link/20240913090631.1834543-5-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-09-13ASoC: sdw_util/intel: move soundwire endpoint and dai link structuresVijendar Mukunda
Move Soundwire endpoint and dai link structures from Intel generic machine driver code to common place holder(soc_sdw_utils.h). These structures will be used in other platform SoundWire machine driver code. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://patch.msgid.link/20240913090631.1834543-4-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-09-12ASoC: SOF: Intel: hda: remove common_hdmi_codec_drvBrent Lu
Do not set common_hdmi_codec_drv in SOF platform driver since no machine driver needs it. Remove member variable common_hdmi_codec_drv from snd_soc_acpi_mach_params structure. Signed-off-by: Brent Lu <brent.lu@intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://patch.msgid.link/20240912120308.134762-6-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-09-11ALSA: pcm: Fix breakage of PCM rates used for topologyTakashi Iwai
It turned out that the topology ABI takes the standard PCM rate bits as is, and it means that the recent change of the PCM rate bits would lead to the inconsistent rate values used for topology. This patch reverts the original PCM rate bit definitions while adding the new rates to the extended bits instead. This needed the change of snd_pcm_known_rates, too. And this also required to fix the handling in snd_pcm_hw_limit_rates() that blindly assumed that the list is sorted while it became unsorted now. Fixes: 090624b7dc83 ("ALSA: pcm: add more sample rate definitions") Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Closes: https://lore.kernel.org/1ab3efaa-863c-4dd0-8f81-b50fd9775fad@linux.intel.com Reviewed-by: Jaroslav Kysela <perex@perex.cz> Tested-by: Jerome Brunet <jbrunet@baylibre.com> Tested-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://patch.msgid.link/20240911135756.24434-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-09-10Merge branch 'for-linus' into for-nextTakashi Iwai
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-09-07ALSA: IEC958 definition for consumer status channel updateJerome Brunet
Add 128kHz, 352.4kHz, 384kHz and 705.6kHz. These definitions have been found working on eARC using a Murideo Seven Generator. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://patch.msgid.link/20240906093422.2976550-1-jbrunet@baylibre.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-09-06ASoC: makes rtd->initialized bit fieldKuninori Morimoto
rtd->initialized is used to know whether soc_init_pcm_runtime() was correctly fined, and used to call snd_soc_link_exit(). We don't need to have it as bool, let's make it bit-field same as other flags. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Cc: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Cc: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://patch.msgid.link/87o752k7gq.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-09-06ALSA: pcm: add more sample rate definitionsJerome Brunet
This adds a sample rate definition for 12kHz, 24kHz and 128kHz. Admittedly, just a few drivers are currently using these sample rates but there is enough of a recurrence to justify adding a definition for them and remove some custom rate constraint code while at it. The new definitions are not added to the interval definitions, such as SNDRV_PCM_RATE_8000_44100, because it would silently add new supported rates to drivers that may or may not support them. For sure the drivers have not been tested for these new rates so it is better to leave them out of interval definitions. That being said, the added rates are multiples of well know rates families, it is very likely that a lot of devices out there actually supports them. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Reviewed-by: David Rhodes <drhodes@opensource.cirrus.com> Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20240905-alsa-12-24-128-v1-1-8371948d3921@baylibre.com
2024-09-06Merge tag 'asoc-fix-v6.11-rc6' of ↵Takashi Iwai
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v6.11 A larger set of fixes than I'd like at this point, but mainly due to people working on fixing module autoloading by adding missing exports of ID tables rather than anything particularly concerning. There are some other runtime fixes and quirks, and a tweak to the ABI definition for SOF which ensures that a struct layout doesn't vary depending on the architecture of the host.
2024-08-28ASoC: Intel: boards: updates for 6.12Mark Brown
Merge series from Bard Liao <yung-chuan.liao@linux.intel.com>: Some simplifications from Brent Lu for Chromebooks, a new SoundWire codec support from Bard Liao, new cs42l43 match entries support from Charles Keepax, Add quirks from some new Dell laptops from Maciej Strozek, some ACPI match entries from Balamurugan C, and few bug fixes from Pierre-Louis Bossart. v2: - Add "ASoC: SOF: Intel: hda: support BT link mask in mach_params" commit to fix the build issue in v1. Balamurugan C (2): ASoC: Intel: soc-acpi: Add entry for sof_es8336 in ARL match table. ASoC: Intel: soc-acpi: Add entry for HDMI_In capture support in ARL match table Bard Liao (4): ASoC: Intel: sof_sdw: add rt1320 amp support ASoC: SOF: Intel: hda: refactoring topology name fixup for HDA mach ASoC: Intel: sof_sdw: move ignore_internal_dmic check earlier ASoC: Intel: sof_sdw: overwrite mach_params->dmic_num Brent Lu (5): ASoC: SOF: Intel: hda: refactoring topology name fixup for SDW mach ASoC: SOF: Intel: hda: support BT link mask in mach_params ASoC: Intel: skl_hda_dsp_generic: support BT audio offload ASoC: Intel: skl_hda_dsp_generic: remove hdac-hdmi support ASoC: Intel: skl_hda_dsp_generic: use sof_hdmi_private to init HDMI Charles Keepax (3): ASoC: Intel: soc-acpi: arl: Add match entries for new cs42l43 laptops ASoC: Intel: soc-acpi: adl: Add match entries for new cs42l43 laptops ASoC: Intel: soc-acpi: lnl: Add match entries for new cs42l43 laptops Maciej Strozek (1): ASoC: Intel: sof_sdw: Add quirks from some new Dell laptops Pierre-Louis Bossart (2): ASoC: Intel: sof_sdw: make sof_sdw_quirk static ASoC: Intel: boards: always check the result of acpi_dev_get_first_match_dev() include/sound/soc-acpi.h | 2 + sound/soc/intel/boards/Kconfig | 2 +- sound/soc/intel/boards/bytcht_cx2072x.c | 4 + sound/soc/intel/boards/bytcht_da7213.c | 4 + sound/soc/intel/boards/bytcht_es8316.c | 2 +- sound/soc/intel/boards/bytcr_rt5640.c | 2 +- sound/soc/intel/boards/bytcr_rt5651.c | 2 +- sound/soc/intel/boards/cht_bsw_rt5645.c | 4 + sound/soc/intel/boards/cht_bsw_rt5672.c | 4 + sound/soc/intel/boards/skl_hda_dsp_common.c | 56 ++-- sound/soc/intel/boards/skl_hda_dsp_common.h | 39 +-- sound/soc/intel/boards/skl_hda_dsp_generic.c | 58 ++-- sound/soc/intel/boards/sof_es8336.c | 12 +- sound/soc/intel/boards/sof_sdw.c | 85 +++++- sound/soc/intel/boards/sof_sdw_common.h | 2 - sound/soc/intel/boards/sof_wm8804.c | 4 + .../intel/common/soc-acpi-intel-adl-match.c | 105 +++++++ .../intel/common/soc-acpi-intel-arl-match.c | 244 +++++++++++++++ .../intel/common/soc-acpi-intel-hda-match.c | 12 +- .../intel/common/soc-acpi-intel-lnl-match.c | 104 +++++++ sound/soc/sdw_utils/soc_sdw_rt_amp.c | 11 +- sound/soc/sdw_utils/soc_sdw_utils.c | 19 ++ sound/soc/sof/intel/hda.c | 281 ++++++++---------- 23 files changed, 780 insertions(+), 278 deletions(-) -- 2.43.0
2024-08-28ASoC: soc-pcm: makes snd_soc_dpcm_can_be_xxx() local functionKuninori Morimoto
No driver is calling snd_soc_dpcm_can_be_xxx() functions. We don't need to have EXPORT_SYMBOL_GPL() for them. Let's makes it static function. One note is that snd_soc_dpcm_fe_can_update() is not used in upstream. Use #if-endif and keep it for future support. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/87h6b6df7e.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-08-28ASoC: SOF: Intel: hda: support BT link mask in mach_paramsBrent Lu
Add an new variable bt_link_mask to snd_soc_acpi_mach_params structure. SSP port mask of BT offload found in NHLT table will be sent to machine driver to setup BE dai link with correct SSP port number. This patch only detects and enables the BT dailink. The functionality will only be unlocked with a topology file that makes a reference to that BT dailink. For backwards-compatibility reasons, this topology will not be used by default. Chromebooks and Linux users willing to experiment shall use the tplg_name kernel parameter to force the use of an enhanced topology. Signed-off-by: Brent Lu <brent.lu@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://patch.msgid.link/20240827123215.258859-9-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-08-27ALSA: pcm: Drop PCM vmalloc buffer helpersTakashi Iwai
As the last-standing user of PCM vmalloc buffer helper API took its own buffer management, we can finally drop those API functions, which were leftover after reorganization of ALSA memalloc code. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20240807152725.18948-3-tiwai@suse.de
2024-08-26ASoC: SOF: ipc: replace "enum sof_comp_type" field with "uint32_t"Laurentiu Mihalcea
Normally, the type of enums is "unsigned int" or "int". GCC has the "-fshort-enums" option, which instructs the compiler to use the smallest data type that can hold all the values in the enum (i.e: char, short, int or their unsigned variants). According to the GCC documentation, "-fshort-enums" may be default on some targets. This seems to be the case for SOF when built for a certain 32-bit ARM platform. On Linux, this is not the case (tested with "aarch64-linux-gnu-gcc") which means enums such as "enum sof_comp_type" will end up having different sizes on Linux and SOF. Since "enum sof_comp_type" is used in IPC-related structures such as "struct sof_ipc_comp", this means the fields of the structures will end up being placed at different offsets. This, in turn, leads to SOF not being able to properly interpret data passed from Linux. With this in mind, replace "enum sof_comp_type" from "struct sof_ipc_comp" with "uint32_t". Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://patch.msgid.link/20240826182442.6191-1-laurentiumihalcea111@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-08-22ASoC: grace time for DPCM cleanupMark Brown
Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>: As we discussed in [1], we don't need to use dpcm_playback/capture flag, so we remove it. But we have been using it for 10 years, some driver might get damage. The most likely case is that the device/driver can use both playback/capture, but have only one flag, and not using xxx_only flag. [1/3] patch indicates warning in such case. These adds grace time for DPCM cleanup. I'm not sure when dpcm_xxx will be removed, and Codec check bypass will be error, but maybe v6.12 or v6.13 ? Please check each driver by that time. Previous patch-set try to check both CPU and Codec in DPCM, but we noticed that there are some special DAI which we can't handle today [2]. So I will escape it in this patch-set. [1] https://lore.kernel.org/r/87edaym2cg.wl-kuninori.morimoto.gx@renesas.com [2] https://lore.kernel.org/all/3e67d62d-fe08-4f55-ab5b-ece8a57154f9@linux.intel.com/ Link: https://lore.kernel.org/r/87edaym2cg.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87wmo6dyxg.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87msole5wc.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/871q5tnuok.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87bk4oqerx.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/8734pctmte.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87r0ctwzr4.wl-kuninori.morimoto.gx@renesas.com Link: https://lore.kernel.org/r/87cymvlmki.wl-kuninori.morimoto.gx@renesas.com
2024-08-22ASoC: cs35l56: Make struct regmap_config constRichard Fitzgerald
It's now possible to declare instances of struct regmap_config as const data. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20240822145535.336407-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-08-22ASoC: remove snd_soc_dai_link_set_capabilities()Kuninori Morimoto
dpcm_xxx flags are no longer needed. We need to use xxx_only flags instead if needed, but snd_soc_dai_link_set_capabilities() user adds dpcm_xxx if playback/capture were available. Thus converting dpcm_xxx to xxx_only is not needed. Just remove it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://patch.msgid.link/87r0aiaahh.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-08-22ASoC: soc-pcm: Indicate warning if dpcm_playback/capture were used for ↵Kuninori Morimoto
availability limition I have been wondering why DPCM needs special flag (= dpcm_playback/capture) to use it. Below is the history why it was added to ASoC. (A) In beginning, there was no dpcm_xxx flag on ASoC. It checks channels_min for DPCM, same as current non-DPCM. Let's name it as "validation check" here. if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) { if (cpu_dai->driver->playback.channels_min) playback = 1; if (cpu_dai->driver->capture.channels_min) capture = 1; (B) commit 1e9de42f4324 ("ASoC: dpcm: Explicitly set BE DAI link supported stream directions") force to use dpcm_xxx flag on DPCM. According to this commit log, this is because "Some BE dummy DAI doesn't set channels_min for playback/capture". But we don't know which DAI is it, and not know why it can't/don't have channels_min. Let's name it as "no_chan_DAI" here. According to the code and git-log, it is used as DCPM-BE and is CPU DAI. I think the correct solution was set channels_min on "no_chan_DAI" side, not update ASoC framework side. But everything is under smoke today. if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) { playback = rtd->dai_link->dpcm_playback; capture = rtd->dai_link->dpcm_capture; (C) commit 9b5db059366a ("ASoC: soc-pcm: dpcm: Only allow playback/capture if supported") checks channels_min (= validation check) again. Because DPCM availability was handled by dpcm_xxx flag at that time, but some Sound Card set it even though it wasn't available. Clearly there's a contradiction here. I think correct solution was update Sound Card side instead of ASoC framework. Sound Card side will be updated to handle this issue later (commit 25612477d20b ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")) if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) { ... playback = rtd->dai_link->dpcm_playback && snd_soc_dai_stream_valid(cpu_dai, ...); capture = rtd->dai_link->dpcm_capture && snd_soc_dai_stream_valid(cpu_dai, ...); This (C) patch should have broken "no_chan_DAI" which doesn't have channels_min, but there was no such report during this 4 years. Possibilities case are as follows - No one is using "no_chan_DAI" - "no_chan_DAI" is no longer exist : was removed ? - "no_chan_DAI" is no longer exist : has channels_min ? Because of these history, this dpcm_xxx is unneeded flag today. But because we have been used it for 10 years since (B), it may have been used differently. For example some DAI available both playback/capture, but it set dpcm_playback flag only, in this case dpcm_xxx flag is used as availability limitation. We can use playback_only flag instead in this case, but it is very difficult to find such DAI today. Let's add grace time to remove dpcm_playback/capture flag. This patch don't use dpcm_xxx flag anymore, and indicates warning to use xxx_only flag if both playback/capture were available but using only one of dpcm_xxx flag, and not using xxx_only flag. Link: https://lore.kernel.org/r/87edaym2cg.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://patch.msgid.link/87seuyaahn.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-08-22ASoC: tas2781: mark const variables tas2563_dvc_table as __maybe_unusedShenghao Ding
In case of tas2781, tas2563_dvc_table will be unused, so mark it as __maybe_unused. Signed-off-by: Shenghao Ding <shenghao-ding@ti.com> Link: https://patch.msgid.link/20240822063205.662-1-shenghao-ding@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-08-19ASoC: Intel: Remove skylake driverMark Brown
Merge series from Cezary Rojewski <cezary.rojewski@intel.com>: A spiritual successor to haswell/baytrail removal series [1]. The avs-driver found in sound/soc/intel/avs is a direct replacement to the existing skylake-driver. It covers all features supported by it and more and aligns with the recommended flows and requirements based on Windows driver equivalent. The skylake-driver related UAPI has been removed with "ASoC: Drop soc-topology ABI v4 support" [2]. For the official kernel tree the deprecation begun with v6.0. Most skylake-drivers users moved to avs- or SOF-driver when AudioDSP capabilities are available on the platform or to snd-hda-intel (sound/pci/hda) when such capabilities are not. For the supported trees the deprecation begun with v5.4 with v5.15 being the first where the skylake-driver is disabled entirely. All machine board drivers that consume this DSP driver have their replacements present within sound/soc/intel/avs/boards/ directory. [1]: https://lore.kernel.org/alsa-devel/20201006064907.16277-1-cezary.rojewski@intel.com/ [2]: https://lore.kernel.org/alsa-devel/20240403091629.647267-1-cezary.rojewski@intel.com/
2024-08-17ALSA: seq: Remove unused declarationsYue Haibing
These functions are never implemented and used. Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Link: https://patch.msgid.link/20240817093334.1120002-1-yuehaibing@huawei.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-08-10ALSA: pcm: Add xrun counter for snd_pcm_substreamNorman Bintang
This patch adds an xrun counter to snd_pcm_substream as an alternative to using logs from XRUN_DEBUG_BASIC. The counter provides a way to track the number of xrun occurences, accessible through the /proc interface. The counter is enabled when CONFIG_SND_PCM_XRUN_DEBUG is set. Example output: $ cat /proc/asound/card0/pcm9p/sub0/status owner_pid : 1425 trigger_time: 235.248957291 tstamp : 0.000000000 delay : 1912 avail : 480 avail_max : 1920 ----- hw_ptr : 672000 appl_ptr : 673440 xrun_counter: 3 # (new row) Signed-off-by: Norman Bintang <normanbt@chromium.org> Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org> Tested-by: Chih-Yang Hsia <paulhsia@chromium.org> Reviewed-by: David Riley <davidriley@chromium.org> Link: https://patch.msgid.link/20240809140648.3414349-1-normanbt@chromium.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-08-09Merge branch 'topic/control-lookup-rwlock' into for-nextTakashi Iwai
Pull control lookup optimization changes. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-08-09ASoC: Drop snd_soc_*_get_kcontrol_locked()Takashi Iwai
The recent cleanup in ALSA control core made no difference between snd_ctl_find_id_mixer() and snd_ctl_find_id_mixer_locked(), and the latter is to be dropped. The only user of the left API was ASoC, and that's snd_soc_card_get_kcontrol_locked() and snd_soc_component_get_kcontrol_locked(). This patch drops those functions and rewrites those users to call the variant without locked instead. The test of the API became superfluous, hence dropped as well. As all callers of snd_ctl_find_id_mixer_locked() are gone, snd_ctl_find_id_mixer_locked() is finally dropped, too. Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20240809104234.8488-4-tiwai@suse.de
2024-08-09ALSA: control: Optimize locking for look-upTakashi Iwai
For a fast look-up of a control element via either numid or name matching (enabled via CONFIG_SND_CTL_FAST_LOOKUP), a locking isn't needed at all thanks to Xarray. OTOH, the locking is still needed for a slow linked-list traversal, and that's rather a rare case. In this patch, we reduce the use of locking at snd_ctl_find_*() API functions, and switch from controls_rwsem to controls_rwlock for avoiding unnecessary lock inversions. This also resulted in a nice cleanup, as *_unlocked() version of snd_ctl_find_*() APIs can be dropped. snd_ctl_find_id_mixer_unlocked() is still left just as an alias of snd_ctl_find_id_mixer(), since soc-card.c has a wrapper and there are several users. Once after converting there, we can remove it later. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20240809104234.8488-3-tiwai@suse.de
2024-08-09ALSA: control: Rename ctl_files_rwlock to controls_rwlockTakashi Iwai
We'll re-use the existing rwlock for the protection of control list lookup, too, and now rename it to a more generic name. This is a preliminary change, only the rename of the struct field here, no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20240809104234.8488-2-tiwai@suse.de
2024-08-09Merge tag 'asoc-fix-v6.11-rc2' of ↵Takashi Iwai
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v6.11 Quite a lot of fixes have come in since the merge window, there's some repetitive fixes over the Qualcomm drivers increasing the patch count, along with a large batch of fixes from Cirrus. We also have some quirks and some individual fixes.
2024-08-08ASoC: tas*: Fix up GPIO usageMark Brown
Merge series from Linus Walleij <linus.walleij@linaro.org>: The TI TAS drivers use some legacy GPIO code and headers, this series fixes it up. The TAS2781 is a special case since it adds a handful of lines of deviating code to reconfigure a GPIO line for IRQ mode and then never actually use the IRQ obtained in the code. Is the line used by autonomous hardware? I'm puzzled by this. Anyways the patch suggest how to solve this properly by fixing the parent irqchip and I'm happy to help.
2024-08-08ASoC: Merge fixesMark Brown
So we can apply AMD patches that rely on them.
2024-08-08ALSA: core: Drop snd_print stuff and coTakashi Iwai
Now that all users of snd_print*() are gone, let's drop the functions completely. This also makes CONFIG_SND_VERBOSE_PRINTK redundant, and it's dropped, too. Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20240807133452.9424-55-tiwai@suse.de
2024-08-08ALSA: emux: Use standard print APITakashi Iwai
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Some functions are changed to receive snd_card object for calling dev_*() functions, too. Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20240807133452.9424-44-tiwai@suse.de
2024-08-08ALSA: wavefront: Use standard print APITakashi Iwai
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20240807133452.9424-36-tiwai@suse.de
2024-08-08ALSA: opti9xx: Use standard print APITakashi Iwai
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. The card pointer is stored in struct snd_opti9xx and snd_miro to be referred for dev_*() calls. Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20240807133452.9424-30-tiwai@suse.de
2024-08-08ALSA: es1688: Use standard print APITakashi Iwai
Use the standard print API with dev_*() instead of the old house-baked one. It gives better information and allows dynamically control of debug prints. For referring to the device, introduce snd_card pointer to struct snd_es1688. Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20240807133452.9424-25-tiwai@suse.de
2024-08-08ALSA: vx_core: Drop unused dev fieldTakashi Iwai
The vx_core.dev field has never been set but referred incorrectly at firmware loading. Pass the proper device pointer from card->dev at request_firmware(), and drop the unused dev field from vx_core, too. Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20240807133452.9424-11-tiwai@suse.de
2024-08-07ASoC: tas2781-i2c: Drop weird GPIO codeLinus Walleij
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 <linux/gpio.h> 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 <linus.walleij@linaro.org> Link: https://patch.msgid.link/20240807-asoc-tas-gpios-v2-1-bd0f2705d58b@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-08-07ALSA: usb-audio: Update UMP group attributes for GTB blocks, tooTakashi Iwai
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 <tiwai@suse.de> Link: https://patch.msgid.link/20240807092303.1935-5-tiwai@suse.de
2024-08-06ASoC: remove bespoke trigger supportKuninori Morimoto
Bespoke trigger support was added when Linux v3.5 by this patch. commit 07bf84aaf736781a283b1bd36eaa911453b14574 ("ASoC: dpcm: Add bespoke trigger()") test-component driver is using it, but this is because it indicates used function for debug/trace purpose. Except test-component driver, bespoke trigger has never been used over 10 years in upstream. We can re-support it if needed in the future, but let's remove it for now, because it just noise in upstream. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/87v80ewmdi.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-08-06ALSA: ump: Handle MIDI 1.0 Function Block in MIDI 2.0 protocolTakashi Iwai
The UMP v1.1 spec says in the section 6.2.1: "If a UMP Endpoint declares MIDI 2.0 Protocol but a Function Block represents a MIDI 1.0 connection, then may optionally be used for messages to/from that Function Block." It implies that the driver can (and should) keep MIDI 1.0 CVM exceptionally for those FBs even if UMP Endpoint is running in MIDI 2.0 protocol, and the current driver lacks of it. This patch extends the sequencer port info to indicate a MIDI 1.0 port, and tries to send/receive MIDI 1.0 CVM as is when this port is the source or sink. The sequencer port flag is set by the driver at parsing FBs and GTBs although application can set it to its own user-space clients, too. Link: https://patch.msgid.link/20240806070024.14301-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-08-05ASoC: cs35l56: Handle OTP read latency over SoundWireRichard Fitzgerald
Use the late-read buffer in the CS35L56 SoundWire interface to read OTP memory. The OTP memory has a longer access latency than chip registers and cannot guarantee to return the data value in the SoundWire control response if the bus clock is >4.8 MHz. The Cirrus SoundWire peripheral IP exposes the bridge-to-bus read buffer and status bits. For a read from OTP the bridge status bits are polled to wait for the OTP data to be loaded into the read buffer and the data is then read from there. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: e1830f66f6c6 ("ASoC: cs35l56: Add helper functions for amp calibration") Link: https://patch.msgid.link/20240805140839.26042-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-08-02ASoC/SOF/PCI/Intel: add PantherLake supportMark Brown
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>: Add initial support for the PantherLake platform, and initial ACPI configurations.
2024-08-02Merge tag 'sound-6.11-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A small collection of fixes: - Revert of FireWire changes that caused a long-time regression - Another long-time regression fix for AMD HDMI - MIDI2 UMP fixes - HD-audio Conexant codec fixes and a quirk" * tag 'sound-6.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: hda: Conditionally use snooping for AMD HDMI ALSA: usb-audio: Correct surround channels in UAC1 channel map ALSA: seq: ump: Explicitly reset RPN with Null RPN ALSA: seq: ump: Transmit RPN/NRPN message at each MSB/LSB data reception ALSA: seq: ump: Use the common RPN/bank conversion context ALSA: ump: Explicitly reset RPN with Null RPN ALSA: ump: Transmit RPN/NRPN message at each MSB/LSB data reception Revert "ALSA: firewire-lib: operate for period elapse event in process context" Revert "ALSA: firewire-lib: obsolete workqueue for period update" ALSA: hda/realtek: Add quirk for Acer Aspire E5-574G ALSA: seq: ump: Optimize conversions from SysEx to UMP ALSA: hda/conexant: Mute speakers at suspend / shutdown ALSA: hda/generic: Add a helper to mute speakers at suspend/shutdown ALSA: hda: conexant: Fix headset auto detect fail in the polling mode
2024-08-02ASoC: tas2781: Fix a compiling warning reported by robot kernel test due to ↵Shenghao Ding
adding tas2563_dvc_table Move tas2563_dvc_table into a separate Header file, as only tas2781 codec driver use this table, and hda side codec driver won't use it. Fixes: 75ed63a5ab5d ("ASoC: tas2781: Add new Kontrol to set tas2563 digital Volume") Signed-off-by: Shenghao Ding <shenghao-ding@ti.com> Link: https://patch.msgid.link/20240802072055.1462-1-shenghao-ding@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-08-02ASoC: Intel: soc-acpi: add PTL match tablesPierre-Louis Bossart
For now the tables are basic for mockup devices and headset codec support Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://patch.msgid.link/20240802124011.173820-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-08-02ASoC: soc-component: Add new snd_soc_component_get_kcontrol() helpersCharles Keepax
Add new helper functions snd_soc_component_get_kcontrol() and snd_soc_component_get_kcontrol_locked() that returns a kcontrol by name, but will factor in the components name_prefix, to handle situations where multiple components are present with the same controls. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20240802105734.2309788-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-08-01AMD SOF based generic SoundWire machine driverMark Brown
Merge series from Vijendar Mukunda <Vijendar.Mukunda@amd.com>: This patch series majorly consists of below changes. - Rename structures, macros and codec helper names used in Intel SoundWire generic driver to make it generic. - Move Intel SoundWire driver common structures, macros and codec helper functions to common placeholder so that it can be used by other platform machine driver. - Refactor few SoundWire common codec helper functions. - AMD SOF based generic SoundWire machine driver for ACP 6.3 variant. This work started a couple of months ago to avoid duplication of code that wasn't really Intel-specific in the "sof_sdw" machine driver. The code went through multiple iterations, was tested for multiple weeks and a couple of build issues reported by the Intel kbuild bots were corrected. This is the initial version of SoundWire machine driver for AMD platforms. Additional code refactoring will be done in the next step on the AMD side. Link: https://github.com/thesofproject/linux/pull/5068 Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
2024-08-01ASoC: soc-acpi: add pci revision id field in mach params structureVijendar Mukunda
Few IP's may have same PCI vendor id and device id and different revision id. Add revision id field to the 'snd_soc_acpi_mach_params' so that using this field platform specific implementation can be added in machine driver. Link: https://github.com/thesofproject/linux/pull/5068 Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://patch.msgid.link/20240801111821.18076-7-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-08-01ASoC: intel/sdw_utils: refactor init_dai_link() and init_simple_dai_link()Vijendar Mukunda
To make it generic, refactor existing implementation for init_dai_link() and init_simple_dai_link() as mentioned below. - Move init_dai_link() and init_simple_dai_link() to common place holder - Rename the functions with "asoc_sdw" as prefix. - Pass the platform specific 'platform_component' structure and its size as arguments for init_simple_dai_link() function and allocate one more extra dlc for platform component. - Pass the 'platform_component' and 'num_platforms' as arguments for init_dai_link(). Link: https://github.com/thesofproject/linux/pull/5068 Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://patch.msgid.link/20240801111821.18076-6-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>