summaryrefslogtreecommitdiff
path: root/sound
AgeCommit message (Collapse)AuthorFilesLines
2020-04-20ASoC: meson: axg-card: fix codec-to-codec link setupJerome Brunet1-1/+3
Since the addition of commit 9b5db059366a ("ASoC: soc-pcm: dpcm: Only allow playback/capture if supported"), meson-axg cards which have codec-to-codec links fail to init and Oops: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000128 Internal error: Oops: 96000044 [#1] PREEMPT SMP CPU: 3 PID: 1582 Comm: arecord Not tainted 5.7.0-rc1 pc : invalidate_paths_ep+0x30/0xe0 lr : snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8 Call trace: invalidate_paths_ep+0x30/0xe0 snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8 dpcm_path_get+0x38/0xd0 dpcm_fe_dai_open+0x70/0x920 snd_pcm_open_substream+0x564/0x840 snd_pcm_open+0xfc/0x228 snd_pcm_capture_open+0x4c/0x78 snd_open+0xac/0x1a8 ... While initiliazing the links, ASoC treats the codec-to-codec links of this card type as a DPCM backend. This error eventually leads to the Oops. Most of the card driver code is shared between DPCM backends and codec-to-codec links. The property "no_pcm" marking DCPM BE was left set on codec-to-codec links, leading to this problem. This commit fixes that. Fixes: 0a8f1117a680 ("ASoC: meson: axg-card: add basic codec-to-codec link support") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20200420114511.450560-2-jbrunet@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-20ALSA: usb-audio: Add static mapping table for ALC1220-VB-based mobosTakashi Iwai3-6/+44
TRX40 mobos from MSI and others with ALC1220-VB USB-audio device need yet more quirks for the proper control names. This patch provides the mapping table for those boards, correcting the FU names for volume and mute controls as well as the terminal names for jack controls. It also improves build_connector_control() not to add the directional suffix blindly if the string is given from the mapping table. With this patch applied, the new UCM profiles will be effective. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206873 Link: https://lore.kernel.org/r/20200420062036.28567-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-04-20ALSA: hda: Remove ASUS ROG Zenith from the blacklistTakashi Iwai1-1/+0
The commit 3c6fd1f07ed0 ("ALSA: hda: Add driver blacklist") added a new blacklist for the devices that are known to have empty codecs, and one of the entries was ASUS ROG Zenith II (PCI SSID 1043:874f). However, it turned out that the very same PCI SSID is used for the previous model that does have the valid HD-audio codecs and the change broke the sound on it. This patch reverts the corresponding entry as a temporary solution. Although Zenith II and co will see get the empty HD-audio bus again, it'd be merely resource wastes and won't affect the functionality, so it's no end of the world. We'll need to address this later, e.g. by either switching to DMI string matching or using PCI ID & SSID pairs. Fixes: 3c6fd1f07ed0 ("ALSA: hda: Add driver blacklist") Reported-by: Johnathan Smithinovic <johnathan.smithinovic@gmx.at> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200419071926.22683-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-04-18ALSA: hda/realtek - Fix unexpected init_amp overrideTakashi Iwai1-3/+5
The commit 1c76aa5fb48d ("ALSA: hda/realtek - Allow skipping spec->init_amp detection") changed the way to assign spec->init_amp field that specifies the way to initialize the amp. Along with the change, the commit also replaced a few fixups that set spec->init_amp in HDA_FIXUP_ACT_PROBE with HDA_FIXUP_ACT_PRE_PROBE. This was rather aligning to the other fixups, and not supposed to change the actual behavior. However, this change turned out to cause a regression on FSC S7020, which hit exactly the above. The reason was that there is still one place that overrides spec->init_amp after HDA_FIXUP_ACT_PRE_PROBE call, namely in alc_ssid_check(). This patch fixes the regression by adding the proper spec->init_amp override check, i.e. verifying whether it's still ALC_INIT_UNDEFINED. Fixes: 1c76aa5fb48d ("ALSA: hda/realtek - Allow skipping spec->init_amp detection") Cc: <stable@vger.kernel.org> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207329 Link: https://lore.kernel.org/r/20200418190639.10082-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-04-18ALSA: usb-audio: Filter out unsupported sample rates on Focusrite devicesAlexander Tsoy1-0/+51
Many Focusrite devices supports a limited set of sample rates per altsetting. These includes audio interfaces with ADAT ports: - Scarlett 18i6, 18i8 1st gen, 18i20 1st gen; - Scarlett 18i8 2nd gen, 18i20 2nd gen; - Scarlett 18i8 3rd gen, 18i20 3rd gen; - Clarett 2Pre USB, 4Pre USB, 8Pre USB. Maximum rate is exposed in the last 4 bytes of Format Type descriptor which has a non-standard bLength = 10. Tested-by: Alexey Skobkin <skobkin-ru@ya.ru> Signed-off-by: Alexander Tsoy <alexander@tsoy.me> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200418175815.12211-1-alexander@tsoy.me Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-04-17ASoC: SOF: Intel: add min/max channels for SSP on Baytrail/BroadwellPierre-Louis Bossart2-0/+64
Major regressions were detected by SOF CI on CherryTrail and Broadwell: [ 25.705750] SSP2-Codec: ASoC: no backend playback stream [ 27.923378] SSP2-Codec: ASoC: no users playback at close - state This is root-caused to the introduction of the DAI capability checks with snd_soc_dai_stream_valid(). Its use in soc-pcm.c makes it a requirement for all DAIs to report at least a non-zero min_channels field. For some reason the SSP structures used for SKL+ did provide this information but legacy platforms didn't. Fixes: 9b5db059366ae2 ("ASoC: soc-pcm: dpcm: Only allow playback/capture if supported") Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20200417172014.11760-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-17ASoC: stm32: sai: fix sai probeOlivier Moysan1-7/+5
pcm config must be set before snd_dmaengine_pcm_register() call. Fixes: 0d6defc7e0e4 ("ASoC: stm32: sai: manage rebind issue") Signed-off-by: Olivier Moysan <olivier.moysan@st.com> Link: https://lore.kernel.org/r/20200417142122.10212-1-olivier.moysan@st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-17Merge tag 'sound-5.7-rc2' of ↵Linus Torvalds8-68/+99
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "One significant regression fix is for HD-audio buffer preallocation. In 5.6 it was set to non-prompt for x86 and forced to 0, but this turned out to be problematic for some applications, hence it gets reverted. Distros would need to restore CONFIG_SND_HDA_PREALLOC_SIZE value to the earlier values they've used in the past. Other than that, we've received quite a few small fixes for HD-audio and USB-audio. Most of them are for dealing with the broken TRX40 mobos and the runtime PM without HD-audio codecs" * tag 'sound-5.7-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: hda: call runtime_allow() for all hda controllers ALSA: hda: Allow setting preallocation again for x86 ALSA: hda: Explicitly permit using autosuspend if runtime PM is supported ALSA: hda: Skip controller resume if not needed ALSA: hda: Keep the controller initialization even if no codecs found ALSA: hda: Release resources at error in delayed probe ALSA: hda: Honor PM disablement in PM freeze and thaw_noirq ops ALSA: hda: Don't release card at firmware loading error ALSA: usb-audio: Check mapping at creating connector controls, too ALSA: usb-audio: Don't create jack controls for PCM terminals ALSA: usb-audio: Don't override ignore_ctl_error value from the map ALSA: usb-audio: Filter error from connector kctl ops, too ALSA: hda/realtek - Enable the headset mic on Asus FX505DT ALSA: ctxfi: Remove unnecessary cast in kfree
2020-04-17ALSA: hda/hdmi: Add module option to disable audio component bindingTakashi Iwai1-0/+9
As the recent regression showed, we want sometimes to turn off the audio component binding just for debugging. This patch adds the module option to control it easily without compilation. Fixes: ade49db337a9 ("ALSA: hda/hdmi - Allow audio component for AMD/ATI and Nvidia HDMI") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207223 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200415162523.27499-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-04-16Merge series "ASoC: rsnd: Fixes for multichannel HDMI audio output" from ↵Mark Brown2-5/+5
Matthias Blankertz <matthias.blankertz@cetitec.com>: This fixes two issues in the snd-soc-rcar driver blocking multichannel HDMI audio out: The parent SSI in a multi-SSI configuration is not correctly set up and started, and the SSI->HDMI channel mapping is wrong. With these patches, the following device tree snippet can be used on an r8a7795-based platform (Salvator-X) to enable multichannel HDMI audio on HDMI0: rsnd_port1: port@1 { rsnd_endpoint1: endpoint { remote-endpoint = <&dw_hdmi0_snd_in>; dai-format = "i2s"; bitclock-master = <&rsnd_endpoint1>; frame-master = <&rsnd_endpoint1>; playback = <&ssi0 &ssi1 &ssi2 &ssi9>; }; }; With a capable receiver attached, all of 2ch (stereo), 6ch (e.g. 5.1) and 8ch audio output should work. Matthias Blankertz (2): ASoC: rsnd: Fix parent SSI start/stop in multi-SSI mode ASoC: rsnd: Fix HDMI channel mapping for multi-SSI mode sound/soc/sh/rcar/ssi.c | 8 ++++---- sound/soc/sh/rcar/ssiu.c | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) base-commit: 7111951b8d4973bda27ff663f2cf18b663d15b48 -- 2.26.0
2020-04-16ASoC: codecs: hdac_hdmi: Fix incorrect use of list_for_each_entryAmadeusz Sławiński1-3/+3
If we don't find any pcm, pcm will point at address at an offset from the the list head and not a meaningful structure. Fix this by returning correct pcm if found and NULL if not. Found with coccinelle. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Link: https://lore.kernel.org/r/20200415162849.308-1-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-16ASoC: rsnd: Fix HDMI channel mapping for multi-SSI modeMatthias Blankertz1-1/+1
The HDMI?_SEL register maps up to four stereo SSI data lanes onto the sdata[0..3] inputs of the HDMI output block. The upper half of the register contains four blocks of 4 bits, with the most significant controlling the sdata3 line and the least significant the sdata0 line. The shift calculation has an off-by-one error, causing the parent SSI to be mapped to sdata3, the first multi-SSI child to sdata0 and so forth. As the parent SSI transmits the stereo L/R channels, and the HDMI core expects it on the sdata0 line, this causes no audio to be output when playing stereo audio on a multichannel capable HDMI out, and multichannel audio has permutated channels. Fix the shift calculation to map the parent SSI to sdata0, the first child to sdata1 etc. Signed-off-by: Matthias Blankertz <matthias.blankertz@cetitec.com> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20200415141017.384017-3-matthias.blankertz@cetitec.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-16ASoC: rsnd: Fix parent SSI start/stop in multi-SSI modeMatthias Blankertz1-4/+4
The parent SSI of a multi-SSI setup must be fully setup, started and stopped since it is also part of the playback/capture setup. So only skip the SSI (as per commit 203cdf51f288 ("ASoC: rsnd: SSI parent cares SWSP bit") and commit 597b046f0d99 ("ASoC: rsnd: control SSICR::EN correctly")) if the SSI is parent outside of a multi-SSI setup. Signed-off-by: Matthias Blankertz <matthias.blankertz@cetitec.com> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20200415141017.384017-2-matthias.blankertz@cetitec.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-16ASoC: soc-dai: revert all changes to DAI startup/shutdown sequencePierre-Louis Bossart1-9/+2
On Baytrail/Cherrytrail, the Atom/SST driver fails miserably: [ 9.741953] intel_sst_acpi 80860F28:00: FW Version 01.0c.00.01 [ 9.832992] intel_sst_acpi 80860F28:00: FW sent error response 0x40034 [ 9.833019] intel_sst_acpi 80860F28:00: FW alloc failed ret -4 [ 9.833028] intel_sst_acpi 80860F28:00: sst_get_stream returned err -5 [ 9.833033] sst-mfld-platform sst-mfld-platform: ASoC: DAI prepare error: -5 [ 9.833037] Baytrail Audio Port: ASoC: prepare FE Baytrail Audio Port failed [ 9.853942] intel_sst_acpi 80860F28:00: FW sent error response 0x40034 [ 9.853974] intel_sst_acpi 80860F28:00: FW alloc failed ret -4 [ 9.853984] intel_sst_acpi 80860F28:00: sst_get_stream returned err -5 [ 9.853990] sst-mfld-platform sst-mfld-platform: ASoC: DAI prepare error: -5 [ 9.853994] Baytrail Audio Port: ASoC: prepare FE Baytrail Audio Port failed Commit b56be800f1292 ("ASoC: soc-pcm: call snd_soc_dai_startup()/shutdown() once") was the initial problematic commit. Commit 1ba616bd1a6d5e ("ASoC: soc-dai: fix DAI startup/shutdown sequence") was an attempt to fix things but it does not work on Baytrail, reverting all changes seems necessary for now. Fixes: 1ba616bd1a6d5e ("ASoC: soc-dai: fix DAI startup/shutdown sequence") Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200415030437.23803-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-15ASoC: topology: Fix endianness issueAmadeusz Sławiński1-1/+1
As done in already existing cases, we should use le32_to_cpu macro while accessing hdr->magic. Found with sparse. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Link: https://lore.kernel.org/r/20200415162435.31859-2-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-15ASoC: q6dsp6: q6afe-dai: add missing channels to MI2S DAIsStephan Gerhold1-0/+16
For some reason, the MI2S DAIs do not have channels_min/max defined. This means that snd_soc_dai_stream_valid() returns false, i.e. the DAIs have neither valid playback nor capture stream. It's quite surprising that this ever worked correctly, but in 5.7-rc1 this is now failing badly: :) Commit 0e9cf4c452ad ("ASoC: pcm: check if cpu-dai supports a given stream") introduced a check for snd_soc_dai_stream_valid() before calling hw_params(), which means that the q6i2s_hw_params() function was never called, eventually resulting in: qcom-q6afe aprsvc:q6afe:4:4: no line is assigned ... even though "qcom,sd-lines" is set in the device tree. Commit 9b5db059366a ("ASoC: soc-pcm: dpcm: Only allow playback/capture if supported") now even avoids creating PCM devices if the stream is not supported, which means that it is failing even earlier with e.g.: Primary MI2S: ASoC: no backend playback stream Avoid all that trouble by adding channels_min/max for the MI2S DAIs. Fixes: 24c4cbcfac09 ("ASoC: qdsp6: q6afe: Add q6afe dai driver") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200415150050.616392-1-stephan@gerhold.net Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-15ASoC: soc-pcm: dpcm: Only allow playback/capture if supportedStephan Gerhold1-2/+11
At the moment, PCM devices for DPCM are only created based on the dpcm_playback/capture parameters of the DAI link, without considering if the CPU/FE DAI is actually capable of playback/capture. Normally the dpcm_playback/capture parameter should match the capabilities of the CPU DAI. However, there is no way to set that parameter from the device tree (e.g. with simple-audio-card or qcom sound cards). dpcm_playback/capture are always both set to 1. This causes problems when the CPU DAI does only support playback or capture. Attemting to open that PCM device with an unsupported stream type then results in a null pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000128 Internal error: Oops: 96000044 [#1] PREEMPT SMP CPU: 3 PID: 1582 Comm: arecord Not tainted 5.7.0-rc1 pc : invalidate_paths_ep+0x30/0xe0 lr : snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8 Call trace: invalidate_paths_ep+0x30/0xe0 snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8 dpcm_path_get+0x38/0xd0 dpcm_fe_dai_open+0x70/0x920 snd_pcm_open_substream+0x564/0x840 snd_pcm_open+0xfc/0x228 snd_pcm_capture_open+0x4c/0x78 snd_open+0xac/0x1a8 ... ... because the DAI playback/capture_widget is not set in that case. We could add checks there to fix the problem (maybe we should anyway), but much easier is to not expose the device as playback/capture in the first place. Attemting to use that device would always fail later anyway. Add checks for snd_soc_dai_stream_valid() to the DPCM case to avoid exposing playback/capture if it is not supported. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200415104928.86091-1-stephan@gerhold.net Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-15ASoC: sgtl5000: Fix VAG power-on handlingSebastian Reichel2-0/+35
As mentioned slightly out of patch context in the code, there is no reset routine for the chip. On boards where the chip is supplied by a fixed regulator, it might not even be resetted during (e.g. watchdog) reboot and can be in any state. If the device is probed with VAG enabled, the driver's probe routine will generate a loud pop sound when ANA_POWER is being programmed. Avoid this by properly disabling just the VAG bit and waiting the required power down time. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Fabio Estevam <festivem@gmail.com> Link: https://lore.kernel.org/r/20200414181140.145825-1-sebastian.reichel@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14ALSA: hda: call runtime_allow() for all hda controllersHui Wang1-0/+1
Before the pci_driver->probe() is called, the pci subsystem calls runtime_forbid() and runtime_get_sync() on this pci dev, so only call runtime_put_autosuspend() is not enough to enable the runtime_pm on this device. For controllers with vgaswitcheroo feature, the pci/quirks.c will call runtime_allow() for this dev, then the controllers could enter rt_idle/suspend/resume, but for non-vgaswitcheroo controllers like Intel hda controllers, the runtime_pm is not enabled because the runtime_allow() is not called. Since it is no harm calling runtime_allow() twice, here let hda driver call runtime_allow() for all controllers. Then the runtime_pm is enabled on all controllers after the put_autosuspend() is called. Signed-off-by: Hui Wang <hui.wang@canonical.com> Link: https://lore.kernel.org/r/20200414142725.6020-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-04-14ASoC: madera: Remove a couple of stray blank linesCharles Keepax1-4/+0
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200409181311.30247-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14ASoC: wsa881x: mark read_only_wordlength flagSrinivas Kandagatla1-0/+4
WSA881x works in PDM mode so the wordlength is fixed, which also makes the only field "WordLength" in DPN_BlockCtrl1 register a read-only. Writing to this register will throw up errors with Qualcomm Controller. So use ro_blockctrl1_reg flag to mark this field as read-only so that core will not write to this register. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20200414110347.23829-1-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14ASoC: qcom: common: Silence duplicate parse error messagesBjorn Andersson2-6/+2
All error paths in qcom_snd_parse_of() prints more specific error messages, so silence the one in apq8096_platform_probe() and sdm845_snd_platform_probe() to avoid spamming the kernel log. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200406003229.2354631-1-bjorn.andersson@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14soc/stm/stm32_sub_sai: Add missing '\n' in log messagesSebastian Fricke1-1/+1
Message logged by 'dev_xxx()' or 'pr_xxx()' should end with a '\n'. Fixes: 3e086ed("ASoC: stm32: add SAI drivers") Signed-off-by: Sebastian Fricke <sebastian.fricke.linux@gmail.com> Link: https://lore.kernel.org/r/20200413042952.7675-1-sebastian.fricke.linux@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14ASoC: dapm: Remove dapm_connect_dai_link_widgets helperCharles Keepax1-22/+14
This helper is adding very little both it and is one caller are very small functions simply combine the two. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200409181209.30130-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14ASoC: dapm: Move error message to avoid some duplicationCharles Keepax1-12/+4
Move the error message into snd_soc_dapm_new_dai from dapm_connect_dai_pair, since the two copies are almost identical and are the only callers. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200409181209.30130-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14ASoC: Intel: soc-acpi-intel-cml-match: remove useless 'rt1308_2_adr'Jason Yan1-8/+0
Fix the following gcc warning: sound/soc/intel/common/soc-acpi-intel-cml-match.c:116:45: warning: ‘rt1308_2_adr’ defined but not used [-Wunused-const-variable=] static const struct snd_soc_acpi_adr_device rt1308_2_adr[] = { ^~~~~~~~~~~~ Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20200410081117.21319-2-yanaijie@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14ASoC: intel: soc-acpi-intel-icl-match: remove useless 'rt1308_2_adr'Jason Yan1-8/+0
Fix the following gcc warning: sound/soc/intel/common/soc-acpi-intel-icl-match.c:90:45: warning: ‘rt1308_2_adr’ defined but not used [-Wunused-const-variable=] static const struct snd_soc_acpi_adr_device rt1308_2_adr[] = { ^~~~~~~~~~~~ Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200410081117.21319-1-yanaijie@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14ASoC: amd: Fix button configurationAkshu Agrawal1-3/+3
RT5682 buttons were incorrectly mapped. Signed-off-by: Akshu Agrawal <akshu.agrawal@amd.com> Link: https://lore.kernel.org/r/20200414113527.13532-1-akshu.agrawal@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14ASoC: tas571x: disable regulators on failed probePhilipp Puschmann1-5/+15
If probe fails after enabling the regulators regulator_put is called for each supply without having them disabled before. This produces some warnings like WARNING: CPU: 0 PID: 90 at drivers/regulator/core.c:2044 _regulator_put.part.0+0x154/0x15c [<c010f7a8>] (unwind_backtrace) from [<c010c544>] (show_stack+0x10/0x14) [<c010c544>] (show_stack) from [<c012b640>] (__warn+0xd0/0xf4) [<c012b640>] (__warn) from [<c012b9b4>] (warn_slowpath_fmt+0x64/0xc4) [<c012b9b4>] (warn_slowpath_fmt) from [<c04c4064>] (_regulator_put.part.0+0x154/0x15c) [<c04c4064>] (_regulator_put.part.0) from [<c04c4094>] (regulator_put+0x28/0x38) [<c04c4094>] (regulator_put) from [<c04c40cc>] (regulator_bulk_free+0x28/0x38) [<c04c40cc>] (regulator_bulk_free) from [<c0579b2c>] (release_nodes+0x1d0/0x22c) [<c0579b2c>] (release_nodes) from [<c05756dc>] (really_probe+0x108/0x34c) [<c05756dc>] (really_probe) from [<c0575aec>] (driver_probe_device+0xb8/0x16c) [<c0575aec>] (driver_probe_device) from [<c0575d40>] (device_driver_attach+0x58/0x60) [<c0575d40>] (device_driver_attach) from [<c0575da0>] (__driver_attach+0x58/0xcc) [<c0575da0>] (__driver_attach) from [<c0573978>] (bus_for_each_dev+0x78/0xc0) [<c0573978>] (bus_for_each_dev) from [<c0574b5c>] (bus_add_driver+0x188/0x1e0) [<c0574b5c>] (bus_add_driver) from [<c05768b0>] (driver_register+0x74/0x108) [<c05768b0>] (driver_register) from [<c061ab7c>] (i2c_register_driver+0x3c/0x88) [<c061ab7c>] (i2c_register_driver) from [<c0102df8>] (do_one_initcall+0x58/0x250) [<c0102df8>] (do_one_initcall) from [<c01a91bc>] (do_init_module+0x60/0x244) [<c01a91bc>] (do_init_module) from [<c01ab5a4>] (load_module+0x2180/0x2540) [<c01ab5a4>] (load_module) from [<c01abbd4>] (sys_finit_module+0xd0/0xe8) [<c01abbd4>] (sys_finit_module) from [<c01011e0>] (__sys_trace_return+0x0/0x20) Fixes: 3fd6e7d9a146 (ASoC: tas571x: New driver for TI TAS571x power amplifiers) Signed-off-by: Philipp Puschmann <p.puschmann@pironex.de> Link: https://lore.kernel.org/r/20200414112754.3365406-1-p.puschmann@pironex.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14ASoC: dapm: Fix regression introducing multiple copies of DAI widgetsCharles Keepax1-43/+48
Refactoring was done to factor out the linking of DAI widgets into a helper function, dapm_add_valid_dai_widget. However when this was done, a regression was introduced for CODEC to CODEC links. It was over looked that the playback and capture variables persisted across all CODEC DAIs being processed, which ensured that the special DAI widget that is added for CODEC to CODEC links was only created once. This bug causes kernel panics during DAPM shutdown. To stick with the spirit of the original refactoring whilst fixing the issue, variables to hold the DAI widgets are added to snd_soc_dai_link. Furthermore the dapm_add_valid_dai_widget function is renamed to dapm_connect_dai_pair, the function only adds DAI widgets in the CODEC to CODEC case and its primary job is to add routes connecting two DAI widgets, making the original name quite misleading. Fixes: 6c4b13b51aa3 ("ASoC: Add dapm_add_valid_dai_widget helper") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200409181209.30130-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14ASoC: samsung: s3c24xx-i2s: Fix build after removal of DAI suspend/resumeKrzysztof Kozlowski2-57/+56
Commit 450312b640f9 ("ASoC: soc-core: remove DAI suspend/resume") removed the DAI side suspend/resume hooks and switched entirely to component suspend/resume. However the Samsung SoC s3c-i2s-v2 driver was not updated. Move the suspend/resume hooks from s3c-i2s-v2.c to s3c2412-i2s.c while changing dai to component which allows to keep the struct snd_soc_component_driver const. This fixes build errors: sound/soc/samsung/s3c-i2s-v2.c: In function ‘s3c_i2sv2_register_component’: sound/soc/samsung/s3c-i2s-v2.c:730:9: error: ‘struct snd_soc_dai_driver’ has no member named ‘suspend’ dai_drv->suspend = s3c2412_i2s_suspend; Reported-by: Arnd Bergmann <arnd@arndb.de> Fixes: 450312b640f9 ("ASoC: soc-core: remove DAI suspend/resume") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20200413124548.28197-1-krzk@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-13ALSA: hda: Allow setting preallocation again for x86Takashi Iwai1-3/+4
The commit c31427d0d21e ("ALSA: hda: No preallocation on x86 platforms") changed CONFIG_SND_HDA_PREALLOC_SIZE setup and its default to zero for x86, as the preallocation should work almost all cases. However, this expectation was too naive; some applications try to allocate as the max buffer size as possible, and it leads to the memory exhaustion. More badly, the commit changed the kconfig no longer adjustable for x86, so you can't fix it statically (although it can be still adjusted via procfs). So, practically seen, it's more recommended to set a reasonable limit for x86, too. This patch follows to that experience, and changes the default to 2048 and allow the kconfig adjustable again. Fixes: c31427d0d21e ("ALSA: hda: No preallocation on x86 platforms") Cc: <stable@vger.kernel.org> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207223 Link: https://lore.kernel.org/r/20200413201919.24241-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-04-13ALSA: hda: Explicitly permit using autosuspend if runtime PM is supportedRoy Spliet1-1/+3
This fixes runtime PM not working after a suspend-to-RAM cycle at least for the codec-less HDA device found on NVIDIA GPUs. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043 Signed-off-by: Roy Spliet <nouveau@spliet.org> Link: https://lore.kernel.org/r/20200413082034.25166-7-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-04-13ALSA: hda: Skip controller resume if not neededTakashi Iwai2-12/+28
The HD-audio controller does system-suspend and resume operations by directly calling its helpers __azx_runtime_suspend() and __azx_runtime_resume(). However, in general, we don't have to resume always the device fully at the system resume; typically, if a device has been runtime-suspended, we can leave it to runtime resume. Usually for achieving this, the driver would call pm_runtime_force_suspend() and pm_runtime_force_resume() pairs in the system suspend and resume ops. Unfortunately, this doesn't work for the resume path in our case. For handling the jack detection at the system resume, a child codec device may need the (literally) forcibly resume even if it's been runtime-suspended, and for that, the controller device must be also resumed even if it's been suspended. This patch is an attempt to improve the situation. It replaces the direct __azx_runtime_suspend()/_resume() calls with with pm_runtime_force_suspend() and pm_runtime_force_resume() with a slight trick as we've done for the codec side. More exactly: - azx_has_pm_runtime() check is dropped from azx_runtime_suspend() and azx_runtime_resume(), so that it can be properly executed from the system-suspend/resume path - The WAKEEN handling depends on the card's power state now; it's set and cleared only for the runtime-suspend - azx_resume() checks whether any codec may need the forcible resume beforehand. If the forcible resume is required, it does temporary PM refcount up/down for actually triggering the runtime resume. - A new helper function, hda_codec_need_resume(), is introduced for checking whether the codec needs a forcible runtime-resume, and the existing code is rewritten with that. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043 Link: https://lore.kernel.org/r/20200413082034.25166-6-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-04-13ALSA: hda: Keep the controller initialization even if no codecs foundTakashi Iwai1-5/+7
Currently, when the HD-audio controller driver doesn't detect any codecs, it tries to abort the probe. But this abort happens at the delayed probe, i.e. the primary probe call already returned success, hence the driver is never unbound until user does so explicitly. As a result, it may leave the HD-audio device in the running state without the runtime PM. More badly, if the device is a HD-audio bus that is tied with a GPU, GPU cannot reach to the full power down and consumes unnecessarily much power. This patch changes the logic after no-codec situation; it continues probing without the further codec initialization but keep the controller driver running normally. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043 Tested-by: Roy Spliet <nouveau@spliet.org> Link: https://lore.kernel.org/r/20200413082034.25166-5-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-04-13ALSA: hda: Release resources at error in delayed probeTakashi Iwai2-13/+17
snd-hda-intel driver handles the most of its probe task in the delayed work (either via workqueue or via firmware loader). When an error happens in the later delayed probe, we can't deregister the device itself because the probe callback already returned success and the device was bound. So, for now, we set hda->init_failed flag and make the rest untouched until the device gets really unbound. However, this leaves the device up running, keeping the resources without any use that prevents other operations. In this patch, we release the resources at first when a probe error happens in the delayed probe stage, but keeps the top-level object, so that the PM and other ops can still refer to the object itself. Also for simplicity, snd_hda_intel object is allocated via devm, so that we can get rid of the explicit kfree calls. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043 Link: https://lore.kernel.org/r/20200413082034.25166-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-04-13ALSA: hda: Honor PM disablement in PM freeze and thaw_noirq opsTakashi Iwai1-0/+4
freeze_noirq and thaw_noirq need to check the PM availability like other PM ops. There are cases where the device got disabled due to the error, and the PM operation should be ignored for that. Fixes: 3e6db33aaf1d ("ALSA: hda - Set SKL+ hda controller power at freeze() and thaw()") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043 Link: https://lore.kernel.org/r/20200413082034.25166-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-04-13ALSA: hda: Don't release card at firmware loading errorTakashi Iwai1-14/+5
At the error path of the firmware loading error, the driver tries to release the card object and set NULL to drvdata. This may be referred badly at the possible PM action, as the driver itself is still bound and the PM callbacks read the card object. Instead, we continue the probing as if it were no option set. This is often a better choice than the forced abort, too. Fixes: 5cb543dba986 ("ALSA: hda - Deferred probing with request_firmware_nowait()") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043 Link: https://lore.kernel.org/r/20200413082034.25166-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-04-12ALSA: usb-audio: Check mapping at creating connector controls, tooTakashi Iwai2-8/+14
Add the mapping check to build_connector_control() so that the device specific quirk can provide the node to skip for the badly behaving connector controls. As an example, ALC1220-VB-based codec implements the skip entry for the broken SPDIF connector detection. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206873 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200412081331.4742-5-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-04-12ALSA: usb-audio: Don't create jack controls for PCM terminalsTakashi Iwai1-3/+6
Some funky firmwares set the connector flag even on PCM terminals although it doesn't make sense (and even actually the firmware doesn't react properly!). Let's skip creation of jack controls in such a case. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206873 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200412081331.4742-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-04-12ALSA: usb-audio: Don't override ignore_ctl_error value from the mapTakashi Iwai1-1/+1
The mapping table may contain also ignore_ctl_error flag for devices that are known to behave wild. Since this flag always writes the card's own ignore_ctl_error flag, it overrides the value already set by the module option, so it doesn't follow user's expectation. Let's fix the code not to clear the flag that has been set by user. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206873 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200412081331.4742-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-04-12ALSA: usb-audio: Filter error from connector kctl ops, tooTakashi Iwai1-1/+1
The ignore_ctl_error option should filter the error at kctl accesses, but there was an overlook: mixer_ctl_connector_get() returns an error from the request. This patch covers the forgotten code path and apply filter_error() properly. The locking error is still returned since this is a fatal error that has to be reported even with ignore_ctl_error option. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206873 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200412081331.4742-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-04-11ALSA: hda/realtek - Enable the headset mic on Asus FX505DTAdam Barber1-0/+1
On Asus FX505DT with Realtek ALC233, the headset mic is connected to pin 0x19, with default 0x411111f0. Enable headset mic by reconfiguring the pin to an external mic associated with the headphone on 0x21. Mic jack detection was also found to be working. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207131 Signed-off-by: Adam Barber <barberadam995@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200410090032.2759-1-barberadam995@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-04-10Merge tag 'sound-fix-5.7-rc1' of ↵Linus Torvalds29-39/+324
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "A collection of small fixes gathered since the previous update. ALSA core: - Regression fix for OSS PCM emulation ASoC: - Trivial fixes in reg bit mask ops, DAPM, DPCM and topology - Lots of fixes for Intel-based devices - Minor fixes for AMD, STM32, Qualcomm, Realtek Others: - Fixes for the bugs in mixer handling in HD-audio and ice1724 drivers that were caught by the recent kctl validator - New quirks for HD-audio and USB-audio Also this contains a fix for EDD firmware fix, which slipped from anyone's hands" * tag 'sound-fix-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (35 commits) ALSA: hda: Add driver blacklist ALSA: usb-audio: Add mixer workaround for TRX40 and co ALSA: hda/realtek - Add quirk for MSI GL63 ALSA: ice1724: Fix invalid access for enumerated ctl items ALSA: hda: Fix potential access overflow in beep helper ASoC: cs4270: pull reset GPIO low then high ALSA: hda/realtek - Add HP new mute led supported for ALC236 ALSA: hda/realtek - Add supported new mute Led for HP ASoC: rt5645: Add platform-data for Medion E1239T ASoC: Intel: bytcr_rt5640: Add quirk for MPMAN MPWIN895CL tablet ASoC: stm32: sai: Add missing cleanup ALSA: usb-audio: Add registration quirk for Kingston HyperX Cloud Alpha S ASoC: Intel: atom: Fix uninitialized variable compiler warning ASoC: Intel: atom: Check drv->lock is locked in sst_fill_and_send_cmd_unlocked ASoC: Intel: atom: Take the drv->lock mutex before calling sst_send_slot_map() ASoC: SOF: Turn "firmware boot complete" message into a dbg message ALSA: usb-audio: Add Pioneer DJ DJM-250MK2 quirk ALSA: pcm: oss: Fix regression by buffer overflow fix (again) ALSA: pcm: oss: Fix regression by buffer overflow fix edd: Use scnprintf() for avoiding potential buffer overflow ...
2020-04-09ALSA: ctxfi: Remove unnecessary cast in kfreeXu Wang1-7/+7
Remove unnecassary casts in the argument to kfree. Signed-off-by: Xu Wang <vulab@iscas.ac.cn> Link: https://lore.kernel.org/r/20200409112052.13402-1-vulab@iscas.ac.cn Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-04-09ASoC: topology: Check return value of soc_tplg_dai_configAmadeusz Sławiński1-2/+7
Function soc_tplg_dai_config can fail, check for and handle possible failure. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200327204729.397-7-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-09ASoC: topology: Check return value of pcm_new_verAmadeusz Sławiński1-1/+3
Function pcm_new_ver can fail, so we should check it's return value and handle possible error. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200327204729.397-6-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-09ASoC: topology: Check soc_tplg_add_route return valueAmadeusz Sławiński1-1/+3
Function soc_tplg_add_route can propagate error code from callback, we should check its return value and handle fail in correct way. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200327204729.397-5-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-09ASoC: topology: Check return value of soc_tplg_*_createAmadeusz Sławiński1-6/+12
Functions soc_tplg_denum_create, soc_tplg_dmixer_create, soc_tplg_dbytes_create can fail, so their return values should be checked and error should be propagated. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200327204729.397-4-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-09ASoC: topology: Check return value of soc_tplg_create_tlvAmadeusz Sławiński1-2/+14
Function soc_tplg_create_tlv can fail, so we should check if it succeded or not and proceed appropriately. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200327204729.397-3-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-08-04 16:49:41 +0300