aboutsummaryrefslogtreecommitdiffstats
path: root/sound/soc (follow)
AgeCommit message (Collapse)AuthorFilesLines
2020-01-14ASoC: Intel: bxt_da7219_max98357a: rename shadowed variablePierre-Louis Bossart1-5/+5
Fix cppcheck warning: [sound/soc/intel/boards/bxt_da7219_max98357a.c:265] -> [sound/soc/intel/boards/bxt_da7219_max98357a.c:164]: (style) Local variable 'channels' shadows outer variable [sound/soc/intel/boards/bxt_da7219_max98357a.c:265] -> [sound/soc/intel/boards/bxt_da7219_max98357a.c:316]: (style) Local variable 'channels' shadows outer variable Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200113210428.27457-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-14ASoC: SOF: Intel: hda-dai: fix compilation warning in pcm_preparePierre-Louis Bossart1-3/+0
Fix GCC warning with W=1, previous cleanup did not remove unnecessary variable. sound/soc/sof/intel/hda-dai.c: In function ‘hda_link_pcm_prepare’: sound/soc/sof/intel/hda-dai.c:265:31: warning: variable ‘hda_stream’ set but not used [-Wunused-but-set-variable] 265 | struct sof_intel_hda_stream *hda_stream; | ^~~~~~~~~~ Fixes: a3ebccb52efdf ("ASoC: SOF: Intel: hda: reset link DMA state in prepare") Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200113205620.27285-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-14ASoC: rt715: remove warningsPierre-Louis Bossart1-2/+2
make W=1 reports defined-but-not-used and kernel-doc formatting issues. No functionality change. Fixes: d1ede0641b05e4 ("ASoC: rt715: add RT715 codec driver") Cc: Jack Yu <jack.yu@realtek.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200113223625.15995-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-14ASoC: rt715: use dev_to_sdw_dev() instead of to_sdw_slave_device()Kuninori Morimoto1-1/+1
This patch fixup this error CC sound/soc/codecs/rt715-sdw.o linux/sound/soc/codecs/rt715-sdw.c: In function 'rt715_dev_resume': linux/sound/soc/codecs/rt715-sdw.c:568:28: error: implicit declaration\ of function 'to_sdw_slave_device'; did you mean 'sdw_slave_modalias'?\ [-Werror=implicit-function-declaration] struct sdw_slave *slave = to_sdw_slave_device(dev); ^~~~~~~~~~~~~~~~~~~ sdw_slave_modalias linux/sound/soc/codecs/rt715-sdw.c:568:28: warning: initialization of\ 'struct sdw_slave *' from 'int' makes pointer from integer without a\ cast [-Wint-conversion] cc1: some warnings being treated as errors Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87h80yhm9p.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-14ASoC: rt700: remove unused including <linux/version.h>YueHaibing1-1/+0
Remove including <linux/version.h> that don't need it. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20200114011319.173401-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: rt1308-sdw: add rt1308 SdW amplifier driverShuming Fan4-0/+913
This is the initial amplifier driver for rt1308-sdw. Signed-off-by: Shuming Fan <shumingf@realtek.com> Link: https://lore.kernel.org/r/20200110014606.17333-1-shumingf@realtek.com Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: atmel: fix build error with CONFIG_SND_ATMEL_SOC_DMA=mChen Zhou1-0/+2
If CONFIG_SND_ATMEL_SOC_DMA=m, build error: sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_set_audio': (.text+0x7cd): undefined reference to `atmel_pcm_dma_platform_register' Function atmel_pcm_dma_platform_register is defined under CONFIG SND_ATMEL_SOC_DMA, so select SND_ATMEL_SOC_DMA in CONFIG SND_ATMEL_SOC_SSC, same to CONFIG_SND_ATMEL_SOC_PDC. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Chen Zhou <chenzhou10@huawei.com> Link: https://lore.kernel.org/r/20200113133242.144550-1-chenzhou10@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: msm8916-wcd-digital: Reset RX interpolation path after useStephan Gerhold1-0/+6
For some reason, attempting to route audio through QDSP6 on MSM8916 causes the RX interpolation path to get "stuck" after playing audio a few times. In this situation, the analog codec part is still working, but the RX path in the digital codec stops working, so you only hear the analog parts powering up. After a reboot everything works again. So far I was not able to reproduce the problem when using lpass-cpu. The downstream kernel driver avoids this by resetting the RX interpolation path after use. In mainline we do something similar for the TX decimator (LPASS_CDC_CLK_TX_RESET_B1_CTL), but the interpolator reset (LPASS_CDC_CLK_RX_RESET_CTL) got lost when the msm8916-wcd driver was split into analog and digital. Fix this problem by adding the reset to msm8916_wcd_digital_enable_interpolator(). Fixes: 150db8c5afa1 ("ASoC: codecs: Add msm8916-wcd digital codec") Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200105102753.83108-1-stephan@gerhold.net Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: msm8916-wcd-analog: Fix MIC BIAS Internal1Stephan Gerhold1-3/+13
MIC BIAS Internal1 is broken at the moment because we always enable the internal rbias resistor to the TX2 line (connected to the headset microphone), rather than enabling the resistor connected to TX1. Move the RBIAS code to pm8916_wcd_analog_enable_micbias_int1/2() to fix this. Fixes: 585e881e5b9e ("ASoC: codecs: Add msm8916-wcd analog codec") Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200111164006.43074-3-stephan@gerhold.net Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: cros_ec_codec: Make the device acpi compatibleYu-Hsuan Hsu1-0/+8
Add ACPI entry for cros_ec_codec. Signed-off-by: Yu-Hsuan Hsu <yuhsuan@chromium.org> Link: https://lore.kernel.org/r/20200112054900.236576-1-yuhsuan@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: sti: fix possible sleep-in-atomicArnaud Pouliquen1-3/+4
Change mutex and spinlock management to avoid sleep in atomic issue. Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Link: https://lore.kernel.org/r/20200113100400.30472-1-arnaud.pouliquen@st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: msm8916-wcd-analog: Fix selected events for MIC BIAS External1Stephan Gerhold1-2/+2
MIC BIAS External1 sets pm8916_wcd_analog_enable_micbias_ext1() as event handler, which ends up in pm8916_wcd_analog_enable_micbias_ext(). But pm8916_wcd_analog_enable_micbias_ext() only handles the POST_PMU event, which is not specified in the event flags for MIC BIAS External1. This means that the code in the event handler is never actually run. Set SND_SOC_DAPM_POST_PMU as the only event for the handler to fix this. Fixes: 585e881e5b9e ("ASoC: codecs: Add msm8916-wcd analog codec") Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200111164006.43074-2-stephan@gerhold.net Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: hdac_hda: Fix error in driver removal after failed probeKai Vehmanen1-1/+3
In case system has multiple HDA codecs, and codec probe fails for at least one but not all codecs, driver will end up cancelling a non-initialized timer context upon driver removal. Call trace of typical case: [ 60.593646] WARNING: CPU: 1 PID: 1147 at kernel/workqueue.c:3032 __flush_work+0x18b/0x1a0 [...] [ 60.593670] __cancel_work_timer+0x11f/0x1a0 [ 60.593673] hdac_hda_dev_remove+0x25/0x30 [snd_soc_hdac_hda] [ 60.593674] device_release_driver_internal+0xe0/0x1c0 [ 60.593675] bus_remove_device+0xd6/0x140 [ 60.593677] device_del+0x175/0x3e0 [ 60.593679] ? widget_tree_free.isra.7+0x90/0xb0 [snd_hda_core] [ 60.593680] snd_hdac_device_unregister+0x34/0x50 [snd_hda_core] [ 60.593682] snd_hdac_ext_bus_device_remove+0x2a/0x60 [snd_hda_ext_core] [ 60.593684] hda_dsp_remove+0x26/0x100 [snd_sof_intel_hda_common] [ 60.593686] snd_sof_device_remove+0x84/0xa0 [snd_sof] [ 60.593687] sof_pci_remove+0x10/0x30 [snd_sof_pci] [ 60.593689] pci_device_remove+0x36/0xb0 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200110235751.3404-9-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: SOF: Intel: fix HDA codec driver probe with multiple controllersKai Vehmanen1-7/+12
In case system has multiple HDA controllers, it can happen that same HDA codec driver is used for codecs of multiple controllers. In this case, SOF may fail to probe the HDA driver and SOF initialization fails. SOF HDA code currently relies that a call to request_module() will also run device matching logic to attach driver to the codec instance. However if driver for another HDA controller was already loaded and it already loaded the HDA codec driver, this breaks current logic in SOF. In this case the request_module() SOF does becomes a no-op and HDA Codec driver is not attached to the codec instance sitting on the HDA bus SOF is controlling. Typical scenario would be a system with both external and internal GPUs, with driver of the external GPU loaded first. Fix this by adding similar logic as is used in legacy HDA driver where an explicit device_attach() call is done after request_module(). Also add logic to propagate errors reported by device_attach() back to caller. This also works in the case where drivers are not built as modules. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200110235751.3404-8-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: SOF: Intel: lower print level to dbg if we will reinit DSPBard liao1-3/+3
We will reinit DSP in a loop when it fails to initialize the first time, as recommended. So, it is not an error before we finally give up. And reorder the trace to make it more readable. Signed-off-by: Bard liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200110235751.3404-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: SOF: Intel: reference SoundWire machine listsPierre-Louis Bossart1-0/+5
Use static tables to automatically select the relevant configurations. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200110222530.30303-7-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: Intel: common: add match tables for TGL w/ SoundWirePierre-Louis Bossart1-2/+49
RT711 is in SoundWire mode on link0. RT1308 is either on SSP2 or on SoundWire link1 (depending on hardware reworks). Signed-off-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200110222530.30303-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: Intel: common: add match tables for CNL/CFL/CML w/ SoundWireRander Wang3-0/+99
The two configurations are with the Realtek 3-in-1 board requiring all 4 links to be enabled, or basic configuration with the on-board RT700 using link1. For now we only have definitions for CML. CNL and CFL are just placeholders. Signed-off-by: Rander Wang <rander.wang@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200110222530.30303-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: Intel: common: add match tables for ICL w/ SoundWireBard Liao1-0/+98
The two configurations are with the Realtek 3-in-1 board requiring all 4 links to be enabled, or basic configuration with the on-board RT700 using link0. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200110222530.30303-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: SOF: fix PCM playback through ALSA OSS emulationKai Vehmanen1-22/+31
Any app using ALSA OSS emulation on top of SOF will fail to error from OSS SNDCTL_DSP_SETFMT ioctl. Reported initially as an issue with xournalpp (application using PortAudio with an OSS backend), but applies more generally to other apps using OSS as well. Problem is caused by SOF PCM not supporting repeated calls to hw_params(), without matching calls to pcm_free(). This is however exactly what the ALSA OSS PCM code is doing when it is handling the OSS ioctls. The problem will lead to leaking of DSP resources and eventual failure of DSP PCM_PARAMS IPC. BugLink: https://github.com/thesofproject/linux/issues/1510 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200110235751.3404-7-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: Intel: bdw-rt5650: change cpu_dai and platform components for SOFPierre-Louis Bossart1-1/+9
The legacy driver uses dummy cpu_dai and platform, SOF requires actual values to bind. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200110235751.3404-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: Intel: broadwell: change cpu_dai and platform components for SOFPan Xiuli1-1/+9
The legacy driver uses dummy cpu_dai and platform, SOF requires actual values to bind. Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200110235751.3404-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: Intel: bdw-rt5677: change cpu_dai and platform components for SOFPierre-Louis Bossart1-1/+9
The legacy driver uses dummy cpu_dai and platform, SOF requires actual values to bind. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200110235751.3404-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: Intel: bdw-rt5677: fix Kconfig dependenciesPierre-Louis Bossart1-0/+3
The existing machine driver depends on SPI Master capabilities, but the Kconfig does not model this dependency and the SPI controller needs to be selected as well. Without this patch the machine driver probe would fail with the spi-RT5677AA:00 component never registered by the ACPI/LPSS subsystem. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200110235751.3404-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: rt711: remove unused including <linux/version.h>YueHaibing1-1/+0
Remove including <linux/version.h> that don't need it. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20200113013123.47561-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: rt715: add RT715 codec driverJack Yu6-0/+2056
Signed-off-by: Jack Yu <jack.yu@realtek.com> Link: https://lore.kernel.org/r/20200110021821.17843-1-jack.yu@realtek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-13ASoC: txx9: Remove unused rtd variablePaul Burton1-1/+0
Commit a857e073ffc6 ("ASoC: txx9: txx9aclc: remove snd_pcm_ops") removed the last use of the rtd variable but didn't remove its definition, leading to the following warning/error for MIPS rbtx49xx_defconfig builds: sound/soc/txx9/txx9aclc.c: In function 'txx9aclc_pcm_hw_params': sound/soc/txx9/txx9aclc.c:54:30: error: unused variable 'rtd' [-Werror=unused-variable] struct snd_soc_pcm_runtime *rtd = snd_pcm_substream_chip(substream); ^~~ Resolve this by removing the unused variable. Signed-off-by: Paul Burton <paulburton@kernel.org> Fixes: a857e073ffc6 ("ASoC: txx9: txx9aclc: remove snd_pcm_ops") Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Cc: Mark Brown <broonie@kernel.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Cc: alsa-devel@alsa-project.org Link: https://lore.kernel.org/r/20200109191422.334516-1-paulburton@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10ASoC: soc-pcm/soc-compress: use snd_soc_dapm_stream_stop() for SND_SOC_DAPM_STREAM_STOPKuninori Morimoto2-2/+2
dpcm_fe_dai_shutdown() / soc_compr_free_fe() didn't care pmdown_time. We already have snd_soc_dapm_stream_stop() for it. Let's use common method. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87zhewrq9j.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10ASoC: soc-dapm: add snd_soc_dapm_stream_stop()Kuninori Morimoto3-35/+25
When we stop stream, if it was Playback, we might need to care about power down time. In such case, we need to use delayed work. We have same implementation for it at soc-pcm.c and soc-compress.c, but we don't want to have duplicate code. This patch adds snd_soc_dapm_stream_stop(), and share same code. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-By: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/871rs8t4uw.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10ASoC: soc-core: add snd_soc_close_delayed_work()Kuninori Morimoto3-55/+30
We need to setup rtd->close_delayed_work_func. It will be set at snd_soc_dai_compress_new() or soc_new_pcm(). But these setups close_delayed_work() which is same name / same implemantaion, but different local code. To reduce duplicate code, this patch moves it as snd_soc_close_delayed_work() and share same code. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-By: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/8736cot4v2.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10ASoC: soc-core: do pinctrl_pm_select_xxx() as componentKuninori Morimoto2-50/+19
ALSA SoC need to care pinctrl_pm_select_xxx(). It is called at soc-core and soc-pcm. soc-pcm is controlling it for activate DAI. soc-core is controlling it for whole system (= suspend/resume/probe/poweroff). If we focus to soc-core side, it need to care about BIAS level. Then, snd_soc_suspend() only is controlling it by Component base (a). Other functions are DAI base (b). (a) pinctrl_pm_select_xxx(component->dev, xxx); (b) pinctrl_pm_select_xxx(dai->dev, xxx); Because of these unbalance, the code is confusable. Here, dai->dev and component->dev are same pointer. Thus, we can replace it component base. One note here is that it cared DAI (= CPU/Codec) pin before this patch, after this patch, it cares Component (= CPU/Codec/Platform) pin. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-By: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/874kx4t4v6.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10ASoC: soc-core: remove duplicate pinctrl operation when suspendKuninori Morimoto1-3/+0
snd_soc_suspend() are doing below for pinctrl_pm_select_sleep_state() int snd_soc_suspend(struct device *dev) { ... for_each_card_components(card, component) { ... (1) pinctrl_pm_select_sleep_state(component->dev); } for_each_card_rtds(card, rtd) { ... (2) pinctrl_pm_select_sleep_state(cpu_dai->dev); } } (1) is called for all component (CPU/Codec/Platform), and (2) is called for CPU DAIs. Here, component->dev is same as dai->dev. This means, it is called in duplicate on CPU case. This patch removes (2). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-By: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/875zhkt4vc.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10ASoC: soc-core: care .ignore_suspend for Component suspendKuninori Morimoto1-7/+17
Card dai_link has .ignore_suspend, and ALSA SoC cares it when suspend. For example, like this for_each_card_rtds(card, rtd) { if (rtd->dai_link->ignore_suspend) continue; ... } But in snd_soc_suspend(), it doesn't care about it when suspending Component. This patch cares it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/877e20t4vh.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10ASoC: soc-core: rename snd_soc_rtdcom_add() to snd_soc_rtd_add_component()Kuninori Morimoto1-5/+5
We don't have snd_soc_rtdcom_list anymore. Let's rename snd_soc_rtdcom_add() to more understandable snd_soc_rtd_add_component() Reported-by: Sridharan, Ranjani <ranjani.sridharan@intel.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/878smgt4vp.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10ASoC: rt700: add rt700 codec driverShuming Fan6-0/+2310
This is the initial codec driver for rt700. Signed-off-by: Shuming Fan <shumingf@realtek.com> Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200110014552.17252-1-shumingf@realtek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10ASoC: soc-core: remove snd_soc_rtdcom_listKuninori Morimoto4-123/+84
Current ALSA SoC is using struct snd_soc_rtdcom_list to connecting component to rtd by using list_head. struct snd_soc_rtdcom_list { struct snd_soc_component *component; struct list_head list; /* rtd::component_list */ }; struct snd_soc_pcm_runtime { ... struct list_head component_list; /* list of connected components */ ... }; The CPU/Codec/Platform component which will be connected to rtd (a) is indicated via dai_link at snd_soc_add_pcm_runtime() int snd_soc_add_pcm_runtime(...) { ... /* Find CPU from registered CPUs */ rtd->cpu_dai = snd_soc_find_dai(dai_link->cpus); ... (a) snd_soc_rtdcom_add(rtd, rtd->cpu_dai->component); ... /* Find CODEC from registered CODECs */ (b) for_each_link_codecs(dai_link, i, codec) { rtd->codec_dais[i] = snd_soc_find_dai(codec); ... (a) snd_soc_rtdcom_add(rtd, rtd->codec_dais[i]->component); } ... /* Find PLATFORM from registered PLATFORMs */ (b) for_each_link_platforms(dai_link, i, platform) { for_each_component(component) { ... (a) snd_soc_rtdcom_add(rtd, component); } } } It shows, it is possible to know how many components will be connected to rtd by using dai_link->num_cpus dai_link->num_codecs dai_link->num_platforms If so, we can use component pointer array instead of list_head, in such case, code can be more simple. This patch removes struct snd_soc_rtdcom_list that is only of temporary value, and convert to pointer array. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-By: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/87a76wt4wm.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10ASoC: stm32: dfsdm: fix 16 bits recordOlivier Moysan1-6/+6
In stm32_afsdm_pcm_cb function, the transfer size is provided in bytes. However, samples are copied as 16 bits words from iio buffer. Divide by two the transfer size, to copy the right number of samples. Fixes: 1e7f6e1c69f0 ("ASoC: stm32: dfsdm: add 16 bits audio record support") Signed-off-by: Olivier Moysan <olivier.moysan@st.com> Link: https://lore.kernel.org/r/20200110131131.3191-1-olivier.moysan@st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10ASoC: max98090: Drop incorrectly applied duplicate commitMark Brown1-1/+1
This reverts commit 4e93c1294f4b051 (ASoC: max98090: fix incorrect helper in max98090_dapm_put_enum_double()) which was misapplied. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10Merge branch 'for-5.5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into asoc-5.6Mark Brown5-56/+152
2020-01-09ASoC: rt711: add rt711 codec driverShuming Fan6-0/+2365
This is the initial codec driver for rt711. Signed-off-by: Shuming Fan <shumingf@realtek.com> Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191227054445.27223-1-shumingf@realtek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-09ASoC: codecs: add wsa881x amplifier supportSrinivas Kandagatla3-0/+1197
This patch adds support to WSA8810/WSA8815 Class-D Smart Speaker Amplifier. This Amplifier is primarily interfaced with SoundWire. One WSA is used for mono speaker configuration and second one would give stereo setup. This patch is tested on SDM845 based DragonBoard DB845c and Lenovo YOGA C630 Laptop based on SDM850 with WSA8815 speaker amplifiers. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200107135929.3267-3-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-09ASoC: stm32: sai: fix possible circular lockingOlivier Moysan1-54/+140
In current driver, locks can be taken as follows: - Register access: take a lock on regmap config and then on clock. - Master clock provider: take a lock on clock and then on regmap config. This can lead to the circular locking summarized below. Remove peripheral clock management through regmap framework, and manage peripheral clock in driver instead. On register access, lock on clock is taken first, which allows to avoid possible locking issue. [ 6696.561513] ====================================================== [ 6696.567670] WARNING: possible circular locking dependency detected [ 6696.573842] 4.19.49 #866 Not tainted [ 6696.577397] ------------------------------------------------------ [ 6696.583566] pulseaudio/6439 is trying to acquire lock: [ 6696.588697] 87b0a25b (enable_lock){..-.}, at: clk_enable_lock+0x64/0x128 [ 6696.595377] [ 6696.595377] but task is already holding lock: [ 6696.601197] d858f825 (stm32_sai_sub:1342:(sai->regmap_config)->lock){....} ... [ 6696.812513] Possible unsafe locking scenario: [ 6696.812513] [ 6696.818418] CPU0 CPU1 [ 6696.822935] ---- ---- [ 6696.827451] lock(stm32_sai_sub:1342:(sai->regmap_config)->lock); [ 6696.833618] lock(enable_lock); [ 6696.839350] lock(stm32_sai_sub:1342: (sai->regmap_config)->lock); [ 6696.848035] lock(enable_lock); Fixes: 03e78a242a15 ("ASoC: stm32: sai: add h7 support") Signed-off-by: Olivier Moysan <olivier.moysan@st.com> Link: https://lore.kernel.org/r/20200109083254.478-1-olivier.moysan@st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-09ASoC: max98090: fix lockdep warningMarek Szyprowski2-4/+7
Commit 62d5ae4cafb7 ("ASoC: max98090: save and restore SHDN when changing sensitive registers") extended the code for handling many controls by adding a custom put function to them. That new custom put function properly handles relations between codec's hardware registers. However they used card->dapm_mutex to properly serialize those operations. This in turn triggers a lockdep warning about possible circular dependency. Fix this by introducing a separate mutex only for serializing the SHDN hardware register related operations. This fixes the following lockdep warning observed on Exynos4412-based Odroid U3 board: ====================================================== WARNING: possible circular locking dependency detected 5.5.0-rc5-next-20200107 #166 Not tainted ------------------------------------------------------ alsactl/1104 is trying to acquire lock: ed0d50f4 (&card->dapm_mutex){+.+.}, at: max98090_shdn_save+0x1c/0x28 but task is already holding lock: edb4b49c (&card->controls_rwsem){++++}, at: snd_ctl_ioctl+0xcc/0xbb8 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&card->controls_rwsem){++++}: snd_ctl_add_replace+0x3c/0x84 dapm_create_or_share_kcontrol+0x24c/0x2e0 snd_soc_dapm_new_widgets+0x308/0x594 snd_soc_bind_card+0x80c/0xad4 devm_snd_soc_register_card+0x34/0x6c odroid_audio_probe+0x288/0x34c platform_drv_probe+0x6c/0xa4 really_probe+0x200/0x490 driver_probe_device+0x78/0x1f8 bus_for_each_drv+0x74/0xb8 __device_attach+0xd4/0x16c bus_probe_device+0x88/0x90 deferred_probe_work_func+0x3c/0xd0 process_one_work+0x22c/0x7c4 worker_thread+0x44/0x524 kthread+0x130/0x164 ret_from_fork+0x14/0x20 0x0 -> #0 (&card->dapm_mutex){+.+.}: lock_acquire+0xe8/0x270 __mutex_lock+0x9c/0xb18 mutex_lock_nested+0x1c/0x24 max98090_shdn_save+0x1c/0x28 max98090_put_enum_double+0x20/0x40 snd_ctl_ioctl+0x190/0xbb8 ksys_ioctl+0x470/0xaf8 ret_fast_syscall+0x0/0x28 0xbefaa564 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&card->controls_rwsem); lock(&card->dapm_mutex); lock(&card->controls_rwsem); lock(&card->dapm_mutex); *** DEADLOCK *** 1 lock held by alsactl/1104: #0: edb4b49c (&card->controls_rwsem){++++}, at: snd_ctl_ioctl+0xcc/0xbb8 stack backtrace: CPU: 0 PID: 1104 Comm: alsactl Not tainted 5.5.0-rc5-next-20200107 #166 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) (unwind_backtrace) from [<c010e180>] (show_stack+0x10/0x14) (show_stack) from [<c0b2a09c>] (dump_stack+0xb4/0xe0) (dump_stack) from [<c018a1c0>] (check_noncircular+0x1ec/0x208) (check_noncircular) from [<c018c5dc>] (__lock_acquire+0x1210/0x25ec) (__lock_acquire) from [<c018e2d8>] (lock_acquire+0xe8/0x270) (lock_acquire) from [<c0b49678>] (__mutex_lock+0x9c/0xb18) (__mutex_lock) from [<c0b4a110>] (mutex_lock_nested+0x1c/0x24) (mutex_lock_nested) from [<c0839b3c>] (max98090_shdn_save+0x1c/0x28) (max98090_shdn_save) from [<c083a5b8>] (max98090_put_enum_double+0x20/0x40) (max98090_put_enum_double) from [<c080d0e8>] (snd_ctl_ioctl+0x190/0xbb8) (snd_ctl_ioctl) from [<c02cafec>] (ksys_ioctl+0x470/0xaf8) (ksys_ioctl) from [<c0101000>] (ret_fast_syscall+0x0/0x28) ... Fixes: 62d5ae4cafb7 ("ASoC: max98090: save and restore SHDN when changing sensitive registers") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20200108115007.31095-2-m.szyprowski@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-09ASoC: max98090: fix incorrect helper in max98090_dapm_put_enum_double()Marek Szyprowski1-1/+1
Commit 62d5ae4cafb7 ("ASoC: max98090: save and restore SHDN when changing sensitive registers") extended the code for handling "LTENL Mux", "LTENR Mux", "LBENL Mux" and "LBENR Mux" controls by adding a custom max98090_dapm_put_enum_double() function to them. However that function used incorrect helper to get its component object. Fix this by using the proper snd_soc_dapm_* helper. This fixes the following NULL pointer exception observed on Exynos4412-based Odroid U3 board: 8<--- cut here --- Unable to handle kernel NULL pointer dereference at virtual address 000000b0 pgd = (ptrval) [000000b0] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 1104 Comm: alsactl Not tainted 5.5.0-rc5-next-20200107 #166 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) PC is at __mutex_lock+0x54/0xb18 LR is at ___might_sleep+0x3c/0x2e0 ... Process alsactl (pid: 1104, stack limit = 0x(ptrval)) ... [<c0b49630>] (__mutex_lock) from [<c0b4a110>] (mutex_lock_nested+0x1c/0x24) [<c0b4a110>] (mutex_lock_nested) from [<c0839b3c>] (max98090_shdn_save+0x1c/0x28) [<c0839b3c>] (max98090_shdn_save) from [<c083a4f8>] (max98090_dapm_put_enum_double+0x20/0x40) [<c083a4f8>] (max98090_dapm_put_enum_double) from [<c080d0e8>] (snd_ctl_ioctl+0x190/0xbb8) [<c080d0e8>] (snd_ctl_ioctl) from [<c02cafec>] (ksys_ioctl+0x470/0xaf8) [<c02cafec>] (ksys_ioctl) from [<c0101000>] (ret_fast_syscall+0x0/0x28) ... ---[ end trace 0e93f0580f4b9241 ]--- Fixes: 62d5ae4cafb7 ("ASoC: max98090: save and restore SHDN when changing sensitive registers") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20200108115007.31095-1-m.szyprowski@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-09ASoC: max98090: fix incorrect helper in max98090_dapm_put_enum_double()Marek Szyprowski1-1/+1
Commit 62d5ae4cafb7 ("ASoC: max98090: save and restore SHDN when changing sensitive registers") extended the code for handling "LTENL Mux", "LTENR Mux", "LBENL Mux" and "LBENR Mux" controls by adding a custom max98090_dapm_put_enum_double() function to them. However that function used incorrect helper to get its component object. Fix this by using the proper snd_soc_dapm_* helper. This fixes the following NULL pointer exception observed on Exynos4412-based Odroid U3 board: 8<--- cut here --- Unable to handle kernel NULL pointer dereference at virtual address 000000b0 pgd = (ptrval) [000000b0] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 1104 Comm: alsactl Not tainted 5.5.0-rc5-next-20200107 #166 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) PC is at __mutex_lock+0x54/0xb18 LR is at ___might_sleep+0x3c/0x2e0 ... Process alsactl (pid: 1104, stack limit = 0x(ptrval)) ... [<c0b49630>] (__mutex_lock) from [<c0b4a110>] (mutex_lock_nested+0x1c/0x24) [<c0b4a110>] (mutex_lock_nested) from [<c0839b3c>] (max98090_shdn_save+0x1c/0x28) [<c0839b3c>] (max98090_shdn_save) from [<c083a4f8>] (max98090_dapm_put_enum_double+0x20/0x40) [<c083a4f8>] (max98090_dapm_put_enum_double) from [<c080d0e8>] (snd_ctl_ioctl+0x190/0xbb8) [<c080d0e8>] (snd_ctl_ioctl) from [<c02cafec>] (ksys_ioctl+0x470/0xaf8) [<c02cafec>] (ksys_ioctl) from [<c0101000>] (ret_fast_syscall+0x0/0x28) ... ---[ end trace 0e93f0580f4b9241 ]--- Fixes: 62d5ae4cafb7 ("ASoC: max98090: save and restore SHDN when changing sensitive registers") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20200108115007.31095-1-m.szyprowski@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-09ASoC: amd: acp3x: Fix return value check in acp3x_dai_probe()Wei Yongjun1-2/+2
In case of error, the function devm_ioremap() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Fixes: c9fe7db6e884 ("ASoC: amd: Refactoring of DAI from DMA driver") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Link: https://lore.kernel.org/r/20200108035954.51317-1-weiyongjun1@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-07ASoC: gtm601: fix build warningArnd Bergmann1-2/+0
The driver produces warnings without CONFIG_OF, and makes no sense without it either: sound/soc/codecs/gtm601.c:50:34: error: 'bm818_dai' defined but not used [-Werror=unused-variable] static struct snd_soc_dai_driver bm818_dai = { ^~~~~~~~~ sound/soc/codecs/gtm601.c:32:34: error: 'gtm601_dai' defined but not used [-Werror=unused-variable] static struct snd_soc_dai_driver gtm601_dai = { ^~~~~~~~~~ Remove the #ifdef check to avoid the warning. Fixes: 057a317a8d94 ("ASoC: gtm601: add Broadmobi bm818 sound profile") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20200107214846.1284981-1-arnd@arndb.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-07ASoC: SOF: loader: add dynamic debug tracePierre-Louis Bossart1-0/+3
We currently have no trace referring to the firmware path, add a trace to help debug cases where the wrong file might be used. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200107160840.1524-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-07ASoC: SOF: pci: change the default firmware path when the community key is usedPierre-Louis Bossart1-2/+42
Since ApolloLake, Intel platforms require signed firmware. On all Windows platforms the default is to require the Intel production key be used. But some platforms allow for a community key to be used, which allows developers to compile/build their own firmware. In the linux-firmware tree, the default intel/sof path is used for firmwares signed for the production key, and files signed with the community key are located in intel/sof/community. Since we don't have an API to query which key is used on what platforms, we have to rely on DMI-based quirks. Developers can bypass this mechanism by setting a kernel 'fw_path' module parameter. Additional dynamic debug traces are provided to help debug cases where the wrong file might be used. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200107160840.1524-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-07ASoC: Fix NULL dereference at freeingTakashi Iwai1-0/+3
When an ASoC driver with pcm_destruct component ops is freed before the PCM object instantiation (e.g. deferring the probe), it hits an Oops at snd_soc_pcm_component_free() that calls the pcm_destruct ops unconditionally. Fix it by adding a NULL-check of rtd->pcm before calling callbacks. Fixes: c64bfc906600 ("ASoC: soc-core: add new pcm_construct/pcm_destruct") Reported-by: Matthias Brugger <matthias.bgg@gmail.com> Tested-by: Ben Ho <ben.ho@mediatek.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20200107070956.15807-1-tiwai@suse.de Signed-off-by: Mark Brown <broonie@kernel.org>