aboutsummaryrefslogtreecommitdiff
path: root/include/sound
AgeCommit message (Collapse)AuthorFilesLines
2024-10-02ALSA: hda: fix trigger_tstamp_latchedJaroslav Kysela1-1/+1
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 <[email protected]> Signed-off-by: Jaroslav Kysela <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2024-09-14Merge tag 'asoc-v6.12' of ↵Takashi Iwai10-296/+607
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 Ding1-0/+68
Add calibration related kcontrol for speaker impedance calibration and speaker leakage check for Chromebook. Signed-off-by: Shenghao Ding <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-09-13ASoC: sdw_utils/intel: move soundwire endpoint parsing helper functionsVijendar Mukunda1-0/+10
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 <[email protected]> Reviewed-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-09-13ASoC: sdw_util/intel: move soundwire endpoint and dai link structuresVijendar Mukunda1-0/+21
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 <[email protected]> Reviewed-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-09-12ASoC: SOF: Intel: hda: remove common_hdmi_codec_drvBrent Lu1-2/+0
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 <[email protected]> Reviewed-by: Péter Ujfalusi <[email protected]> Signed-off-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-09-11ALSA: pcm: Fix breakage of PCM rates used for topologyTakashi Iwai1-17/+18
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 <[email protected]> Closes: https://lore.kernel.org/[email protected] Reviewed-by: Jaroslav Kysela <[email protected]> Tested-by: Jerome Brunet <[email protected]> Tested-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2024-09-10Merge branch 'for-linus' into for-nextTakashi Iwai1-1/+1
Signed-off-by: Takashi Iwai <[email protected]>
2024-09-07ALSA: IEC958 definition for consumer status channel updateJerome Brunet1-1/+5
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 <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2024-09-06ASoC: makes rtd->initialized bit fieldKuninori Morimoto1-2/+1
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 <[email protected]> Cc: Amadeusz Sławiński <[email protected]> Cc: Cezary Rojewski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-09-06ALSA: pcm: add more sample rate definitionsJerome Brunet1-14/+17
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 <[email protected]> Reviewed-by: David Rhodes <[email protected]> Acked-by: Mark Brown <[email protected]> Reviewed-by: Jaroslav Kysela <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Link: https://patch.msgid.link/[email protected]
2024-09-06Merge tag 'asoc-fix-v6.11-rc6' of ↵Takashi Iwai1-1/+1
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 Brown1-0/+2
Merge series from Bard Liao <[email protected]>: 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 Morimoto1-18/+0
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 <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-28ASoC: SOF: Intel: hda: support BT link mask in mach_paramsBrent Lu1-0/+2
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 <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Signed-off-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-27ALSA: pcm: Drop PCM vmalloc buffer helpersTakashi Iwai1-42/+0
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 <[email protected]> Link: https://patch.msgid.link/[email protected]
2024-08-26ASoC: SOF: ipc: replace "enum sof_comp_type" field with "uint32_t"Laurentiu Mihalcea1-1/+1
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 <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Daniel Baluta <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-22ASoC: grace time for DPCM cleanupMark Brown2-1/+1
Merge series from Kuninori Morimoto <[email protected]>: 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/[email protected] [2] https://lore.kernel.org/all/[email protected]/ Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
2024-08-22ASoC: cs35l56: Make struct regmap_config constRichard Fitzgerald1-3/+3
It's now possible to declare instances of struct regmap_config as const data. Signed-off-by: Richard Fitzgerald <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-22ASoC: remove snd_soc_dai_link_set_capabilities()Kuninori Morimoto1-1/+0
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 <[email protected]> Tested-by: Jerome Brunet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-22ASoC: soc-pcm: Indicate warning if dpcm_playback/capture were used for ↵Kuninori Morimoto1-0/+1
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/[email protected] Signed-off-by: Kuninori Morimoto <[email protected]> Tested-by: Jerome Brunet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-22ASoC: tas2781: mark const variables tas2563_dvc_table as __maybe_unusedShenghao Ding1-1/+1
In case of tas2781, tas2563_dvc_table will be unused, so mark it as __maybe_unused. Signed-off-by: Shenghao Ding <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-19ASoC: Intel: Remove skylake driverMark Brown1-0/+1
Merge series from Cezary Rojewski <[email protected]>: 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/[email protected]/ [2]: https://lore.kernel.org/alsa-devel/[email protected]/
2024-08-17ALSA: seq: Remove unused declarationsYue Haibing1-4/+0
These functions are never implemented and used. Signed-off-by: Yue Haibing <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2024-08-10ALSA: pcm: Add xrun counter for snd_pcm_substreamNorman Bintang1-0/+3
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 <[email protected]> Reviewed-by: Chih-Yang Hsia <[email protected]> Tested-by: Chih-Yang Hsia <[email protected]> Reviewed-by: David Riley <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2024-08-09Merge branch 'topic/control-lookup-rwlock' into for-nextTakashi Iwai6-28/+9
Pull control lookup optimization changes. Signed-off-by: Takashi Iwai <[email protected]>
2024-08-09ASoC: Drop snd_soc_*_get_kcontrol_locked()Takashi Iwai3-12/+0
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 <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Link: https://patch.msgid.link/[email protected]
2024-08-09ALSA: control: Optimize locking for look-upTakashi Iwai2-21/+3
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 <[email protected]> Link: https://patch.msgid.link/[email protected]
2024-08-09ALSA: control: Rename ctl_files_rwlock to controls_rwlockTakashi Iwai1-1/+1
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 <[email protected]> Link: https://patch.msgid.link/[email protected]
2024-08-09Merge tag 'asoc-fix-v6.11-rc2' of ↵Takashi Iwai2-0/+10
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 Brown1-6/+1
Merge series from Linus Walleij <[email protected]>: 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 Brown2-0/+10
So we can apply AMD patches that rely on them.
2024-08-08ALSA: core: Drop snd_print stuff and coTakashi Iwai1-67/+0
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 <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Link: https://patch.msgid.link/[email protected]
2024-08-08ALSA: emux: Use standard print APITakashi Iwai1-2/+4
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 <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Link: https://patch.msgid.link/[email protected]
2024-08-08ALSA: wavefront: Use standard print APITakashi Iwai1-4/+0
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 <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Link: https://patch.msgid.link/[email protected]
2024-08-08ALSA: opti9xx: Use standard print APITakashi Iwai1-0/+1
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 <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Link: https://patch.msgid.link/[email protected]
2024-08-08ALSA: es1688: Use standard print APITakashi Iwai1-0/+1
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 <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Link: https://patch.msgid.link/[email protected]
2024-08-08ALSA: vx_core: Drop unused dev fieldTakashi Iwai1-1/+0
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 <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Link: https://patch.msgid.link/[email protected]
2024-08-07ASoC: tas2781-i2c: Drop weird GPIO codeLinus Walleij1-6/+1
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 <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-07ALSA: usb-audio: Update UMP group attributes for GTB blocks, tooTakashi Iwai1-0/+1
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 <[email protected]> Link: https://patch.msgid.link/[email protected]
2024-08-06ASoC: remove bespoke trigger supportKuninori Morimoto2-5/+1
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 <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-06ALSA: ump: Handle MIDI 1.0 Function Block in MIDI 2.0 protocolTakashi Iwai1-0/+1
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/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2024-08-05ASoC: cs35l56: Handle OTP read latency over SoundWireRichard Fitzgerald1-0/+5
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 <[email protected]> Fixes: e1830f66f6c6 ("ASoC: cs35l56: Add helper functions for amp calibration") Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-02ASoC/SOF/PCI/Intel: add PantherLake supportMark Brown1-0/+2
Merge series from Pierre-Louis Bossart <[email protected]>: Add initial support for the PantherLake platform, and initial ACPI configurations.
2024-08-02Merge tag 'sound-6.11-rc2' of ↵Linus Torvalds1-0/+1
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 Ding2-260/+279
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 <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-02ASoC: Intel: soc-acpi: add PTL match tablesPierre-Louis Bossart1-0/+2
For now the tables are basic for mockup devices and headset codec support Reviewed-by: Péter Ujfalusi <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Bard Liao <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-02ASoC: soc-component: Add new snd_soc_component_get_kcontrol() helpersCharles Keepax1-0/+5
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 <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-01AMD SOF based generic SoundWire machine driverMark Brown2-0/+218
Merge series from Vijendar Mukunda <[email protected]>: 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 <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]>
2024-08-01ASoC: soc-acpi: add pci revision id field in mach params structureVijendar Mukunda1-0/+2
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 <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>