aboutsummaryrefslogtreecommitdiffstats
path: root/sound (follow)
AgeCommit message (Collapse)AuthorFilesLines
2020-01-03ASoC: Intel: boards: Fix compile-testing RT1011/RT5682Arnd Bergmann1-1/+0
On non-x86, the new driver results in a build failure: sound/soc/intel/boards/cml_rt1011_rt5682.c:14:10: fatal error: asm/cpu_device_id.h: No such file or directory The asm/cpu_device_id.h header is not actually needed here, so don't include it. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200102135322.1841053-1-arnd@arndb.de Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-24ASoC: SOF: imx8: Fix dsp_box offsetDaniel Baluta1-0/+3
dsp_box is used to keep DSP initiated messages. The value of dsp_offset is set by the DSP with the first message, so we need a way to bootstrap it in order to get the first message. We do this by setting the correct default dsp_box offset which on i.MX8 is not zero. Very interesting is why it has worked until now. On i.MX8, DSP communicates with ARM core using a shared SDRAM memory area. Actually, there are two shared areas: * SDRAM0 - starting at 0x92400000, size 0x800000 * SDRAM1 - starting at 0x92C00000, size 0x800000 SDRAM0 keeps the data sections, starting with .rodata. By chance fw_ready structure was placed at the beginning of .rodata. dsp_box_base is defined as SDRAM0 + dsp_box_offset and it is placed at the beginning of SDRAM1 (dsp_box_offset should be 0x800000). But because it is zero initialized by default it points to SDRAM0 where by chance the fw_ready was placed in the SOF firmware. Anyhow, SOF commit 7466bee378dd811b ("clk: make freq arrays constant") fw_ready is no longer at the beginning of SDRAM0 and everything shows how lucky we were until now. Fix this by properly setting the default dsp_box offset. Fixes: 202acc565a1f050 ("ASoC: SOF: imx: Add i.MX8 HW support") Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191220170531.10423-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-24ASoC: topology: Prevent use-after-free in snd_soc_get_pcm_runtime()Dragos Tarcatu1-3/+3
remove_link() is currently calling snd_soc_remove_dai_link() after it has already freed the memory for the link name. But this is later read from snd_soc_get_pcm_runtime() causing a KASAN use-after-free warning. Reorder the cleanups to fix this issue. Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Dragos Tarcatu <dragos_tarcatu@mentor.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20191204210447.11701-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-24ASoC: fsl_audmix: add missed pm_runtime_disableChuhong Yuan1-1/+8
The driver forgets to call pm_runtime_disable in probe failure and remove. Add the missed calls to fix it. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Acked-by: Nicolin Chen <nicoleotsuka@gmail.com> Link: https://lore.kernel.org/r/20191203111303.12933-1-hslester96@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-24ASoC: stm32: spdifrx: fix input pin state managementOlivier Moysan1-4/+0
Changing input state in iec capture control is not safe, as the pin state may be changed concurrently by ASoC framework. Remove pin state handling in iec capture control. Note: This introduces a restriction on capture control, when pin sleep state is defined in device tree. In this case channel status can be captured only when an audio stream capture is active. Fixes: f68c2a682d44 ("ASoC: stm32: spdifrx: add power management") Signed-off-by: Olivier Moysan <olivier.moysan@st.com> Link: https://lore.kernel.org/r/20191204154333.7152-4-olivier.moysan@st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-24ASoC: stm32: spdifrx: fix race condition in irq handlerOlivier Moysan1-5/+19
When snd_pcm_stop() is called in interrupt routine, substream context may have already been released. Add protection on substream context. Fixes: 03e4d5d56fa5 ("ASoC: stm32: Add SPDIFRX support") Signed-off-by: Olivier Moysan <olivier.moysan@st.com> Link: https://lore.kernel.org/r/20191204154333.7152-3-olivier.moysan@st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-24ASoC: stm32: spdifrx: fix inconsistent lock stateOlivier Moysan1-5/+7
In current spdifrx driver locks may be requested as follows: - request lock on iec capture control, when starting synchronization. - request lock in interrupt context, when spdifrx stop is called from IRQ handler. Take lock with IRQs disabled, to avoid the possible deadlock. Lockdep report: [ 74.278059] ================================ [ 74.282306] WARNING: inconsistent lock state [ 74.290120] -------------------------------- ... [ 74.314373] CPU0 [ 74.314377] ---- [ 74.314381] lock(&(&spdifrx->lock)->rlock); [ 74.314396] <Interrupt> [ 74.314400] lock(&(&spdifrx->lock)->rlock); Fixes: 03e4d5d56fa5 ("ASoC: stm32: Add SPDIFRX support") Signed-off-by: Olivier Moysan <olivier.moysan@st.com> Link: https://lore.kernel.org/r/20191204154333.7152-2-olivier.moysan@st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-24ASoC: core: Fix access to uninitialized list headsTakashi Iwai1-6/+6
The error path of soc_new_pcm_runtime() invokes soc_free_pcm_runtime() that may cause a few problems. First off, it calls list_del() for rtd->list that may not be initialized. Similarly, snd_soc_pcm_component_free() traverses over the component list that may not be initialized, either. Such access to the uninitialized list head would lead to either a BUG_ON() or a memory corruption. This patch fixes the access to uninitialized list heads by initializing the list heads properly at the beginning before those error paths. Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191204151454.21643-1-tiwai@suse.de Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-24ASoC: soc-core: Set dpcm_playback / dpcm_captureDaniel Baluta1-0/+2
When converting a normal link to a DPCM link we need to set dpcm_playback / dpcm_capture otherwise playback/capture streams will not be created resulting in errors like this: [ 36.039111] sai1-wm8960-hifi: ASoC: no backend playback stream Fixes: a655de808cbde ("ASoC: core: Allow topology to override machine driver FE DAI link config") Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20191204151333.26625-1-daniel.baluta@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-24ASoC: SOF: imx8: fix memory allocation failure check on priv->pd_devColin Ian King1-1/+1
The memory allocation failure check for priv->pd_dev is incorrectly pointer checking priv instead of priv->pd_dev. Fix this. Addresses-Coverity: ("Logically dead code") Fixes: 202acc565a1f ("ASoC: SOF: imx: Add i.MX8 HW support") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191204124816.1415359-1-colin.king@canonical.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-18ASoC: SOF: Intel: hda: hda-dai: fix oops on hda_link .hw_freePierre-Louis Bossart1-2/+9
When the PCM_PARAM IPC fails while configuring the FE, the kernel oopses in the HDaudio link DMA .hw_free operation. The root cause is a NULL dma_data since the BE .hw_params was never called by the SOC core. This error can also happen if the HDaudio link DMA configuration IPC fails in the BE .hw_params. This patches makes sure the dma_data is properly saved in .hw_params, and tested before being use in hw_free. GitHub issue: https://github.com/thesofproject/linux/issues/1417 Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-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/20191218000518.5830-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-18ASoC: SOF: fix fault at driver unload after failed probeKai Vehmanen1-0/+3
If sof_machine_check() fails during driver probe, the IPC state is not initialized and this will lead to a NULL dereference at driver unload. Example log is as follows: [ 1535.980630] sof-audio-pci 0000:00:1f.3: error: no matching ASoC machine driver found - aborting probe [ 1535.980631] sof-audio-pci 0000:00:1f.3: error: failed to get machine info -19 [ 1535.980632] sof-audio-pci 0000:00:1f.3: error: sof_probe_work failed err: -19 [ 1550.798373] BUG: kernel NULL pointer dereference, address: 0000000000000008 ... [ 1550.798393] Call Trace: [ 1550.798397] snd_sof_ipc_free+0x15/0x30 [snd_sof] [ 1550.798399] snd_sof_device_remove+0x29/0xa0 [snd_sof] [ 1550.798400] sof_pci_remove+0x10/0x30 [snd_sof_pci] 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/20191218000518.5830-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-16ASoC: wm8962: fix lambda valueShengjiu Wang1-2/+2
According to user manual, it is required that FLL_LAMBDA > 0 in all cases (Integer and Franctional modes). Fixes: 9a76f1ff6e29 ("ASoC: Add initial WM8962 CODEC driver") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/1576065442-19763-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-10ASoC: Intel: common: work-around incorrect ACPI HID for CML boardsAmery Song1-17/+24
On CML boards with the RT5682 headset codec and RT1011 speaker amplifier, the platform firmware exposes three ACPI HIDs (10EC5682, 10EC1011 and MX98357A). The last HID is a mistake in DSDT tables, which causes the wrong machine driver to be loaded. This patch changes the key used to identify boards and changes the order of entries in the table to load the correct machine driver. The order does matter and should not be modified to work-around this firmware issue. Signed-off-by: Amery Song <chao.song@intel.com> Signed-off-by: Keyon Jie <yang.jie@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191210004854.16845-9-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-10ASoC: SOF: Intel: split cht and byt debug window sizesCurtis Malainey1-3/+4
Turns out SSP 3-5 are only available on cht, to avoid dumping on undefined registers let's split the definition. Signed-off-by: Curtis Malainey <cujomalainey@chromium.org> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191210004854.16845-7-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-10ASoC: SOF: loader: fix snd_sof_fw_parse_ext_dataKarol Trzcinski1-2/+3
An error occurs during parsing more than one ext_data from the mailbox, because of invalid data offset handling. Fix by removing the incorrect duplicate increment of the offset. The return value is also reset in the switch case. This does not change the behavior but improves readability - there is no longer a need to check what the return value of get_ext_windows is. Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com> Signed-off-by: Bartosz Kokoszko <bartoszx.kokoszko@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191210004854.16845-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-10ASoC: SOF: loader: snd_sof_fw_parse_ext_data log warning on unknown headerKarol Trzcinski1-0/+2
Added warning log when found some unknown FW boot ext header, to improve debuggability. Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191210004854.16845-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-10ASoC: simple-card: Don't create separate link when platform is presentDaniel Baluta1-0/+6
In normal sound case all DAIs are detected as CPU-Codec. simple_dai_link_of supports the presence of a platform but it counts it as a CPU DAI resulting in the creation of an extra link. Adding a platform property to a link description like: simple-audio-card,dai-link { cpu { sound-dai = <&sai1>; }; plat { sound-dai = <&dsp>; }; codec { sound-dai = <&wm8960>; } will result in the creation of two links: * sai1 <-> wm8960 * dsp <-> wm8960 which is obviously not what we want. We just want one single link with: * sai1 <-> wm8960 (and platform set to dsp). Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20191209135353.17427-1-daniel.baluta@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-10ASoC: topology: Check return value for soc_tplg_pcm_create()Dragos Tarcatu1-1/+7
The return value of soc_tplg_pcm_create() is currently not checked in soc_tplg_pcm_elems_load(). If an error is to occur there, the topology ignores it and continues loading. Fix that by checking the status and rejecting the topology on error. Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Dragos Tarcatu <dragos_tarcatu@mentor.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191210003939.15752-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-10ASoC: topology: Check return value for snd_soc_add_dai_link()Dragos Tarcatu1-6/+13
snd_soc_add_dai_link() might fail. This situation occurs for instance in a very specific use case where a PCM device and a Back End DAI link are given identical names in the topology. When this happens, soc_new_pcm_runtime() fails and then snd_soc_add_dai_link() returns -ENOMEM when called from soc_tplg_fe_link_create(). Because of that, the link will not get added into the card list, so any attempt to remove it later ends up in a panic. Fix that by checking the return status and free the memory in case of an error. Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Dragos Tarcatu <dragos_tarcatu@mentor.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191210003939.15752-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-09ASoC: core: only flush inited work during freeCurtis Malainey1-1/+2
There are many paths to soc_free_pcm_runtime which can both have and have not yet inited the workqueue yet. When we flush the queue when we have not yet inited the queue we cause warnings to be printed. An example is soc_cleanup_card_resources which is called by snd_soc_bind_card which has multiple failure points before and after soc_link_init -> soc_new_pcm which is where the queue is inited. Signed-off-by: Curtis Malainey <cujomalainey@chromium.org> Link: https://lore.kernel.org/r/20191128011358.39234-1-cujomalainey@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-04ASoC: Intel: bytcr_rt5640: Update quirk for Teclast X89Hans de Goede1-2/+6
When the Teclast X89 quirk was added we did not have jack-detection support yet. Note the over-current detection limit is set to 2mA instead of the usual 1.5mA because this tablet tends to give false-positive button-presses when it is set to 1.5mA. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191203221442.2657-1-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-04ASoC: core: Init pcm runtime work early to avoid warningsCurtis Malainey3-11/+16
There are cases where we fail before we reach soc_new_pcm which would init the workqueue. When we fail we attempt to flush the queue which generates warnings from the workqueue subsystem when we have not inited the queue. Solution is to use a proxy function to get around this issue. Signed-off-by: Curtis Malainey <cujomalainey@chromium.org> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20191203173007.46504-1-cujomalainey@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-03ASoC: Intel: sst: Add missing include <linux/io.h>YueHaibing1-0/+1
Fix build error: sound/soc/intel/atom/sst/sst.c: In function intel_sst_interrupt_mrfld: sound/soc/intel/atom/sst/sst.c:93:5: error: implicit declaration of function memcpy_fromio; did you mean memcpy32_fromio? [-Werror=implicit-function-declaration] memcpy_fromio(msg->mailbox_data, ^~~~~~~~~~~~~ memcpy32_fromio Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191128135853.8360-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-27ASoC: max98090: fix possible race conditionsTzung-Bi Shih2-7/+2
max98090_interrupt() and max98090_pll_work() run in 2 different threads. There are 2 possible races: Note: M98090_REG_DEVICE_STATUS = 0x01. Note: ULK == 0, PLL is locked; ULK == 1, PLL is unlocked. max98090_interrupt max98090_pll_work ---------------------------------------------- schedule max98090_pll_work restart max98090 codec receive ULK INT assert ULK == 0 schedule max98090_pll_work (1). In the case (1), the PLL is locked but max98090_interrupt unnecessarily schedules another max98090_pll_work. max98090_interrupt max98090_pll_work max98090 codec ---------------------------------------------------------------------- ULK = 1 receive ULK INT read 0x01 ULK = 0 (clear on read) schedule max98090_pll_work restart max98090 codec ULK = 1 receive ULK INT read 0x01 ULK = 0 (clear on read) read 0x01 assert ULK == 0 (2). In the case (2), both max98090_interrupt and max98090_pll_work read the same clear-on-read register. max98090_pll_work would falsely thought PLL is locked. Note: the case (2) race is introduced by the previous commit ("ASoC: max98090: exit workaround earlier if PLL is locked") to check the status and exit the loop earlier in max98090_pll_work. There are 2 possible solution options: A. turn off ULK interrupt before scheduling max98090_pll_work; and turn on again before exiting max98090_pll_work. B. remove the second thread of execution. Option A cannot fix the case (2) race because it still has 2 threads access the same clear-on-read register simultaneously. Although we could suppose the register is volatile and read the status via I2C could be much slower than the hardware raises the bits. Option B introduces a maximum 10~12 msec penalty delay in the interrupt handler. However, it could only punish the jack detection by extra 10~12 msec. Adopts option B which is the better solution overall. Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20191122073114.219945-4-tzungbi@google.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-27ASoC: max98090: exit workaround earlier if PLL is lockedTzung-Bi Shih1-2/+12
According to the datasheet, PLL lock time typically takes 2 msec and at most takes 7 msec. Check the lock status every 1 msec and exit the workaround if PLL is locked. Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20191122073114.219945-3-tzungbi@google.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-27ASoC: max98090: remove msleep in PLL unlocked workaroundTzung-Bi Shih1-1/+7
It was observed Baytrail-based chromebooks could cause continuous PLL unlocked when using playback stream and capture stream simultaneously. Specifically, starting a capture stream after started a playback stream. As a result, the audio data could corrupt or turn completely silent. As the datasheet suggested, the maximum PLL lock time should be 7 msec. The workaround resets the codec softly by toggling SHDN off and on if PLL failed to lock for 10 msec. Notably, there is no suggested hold time for SHDN off. On Baytrail-based chromebooks, it would easily happen continuous PLL unlocked if there is a 10 msec delay between SHDN off and on. Removes the msleep(). Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20191122073114.219945-2-tzungbi@google.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-27ASoC: wm8904: fix automatic sysclk configurationMichael Walle1-0/+6
The simple-card tries to signal the codec to disable rate constraints, see commit 2458adb8f92a ("SoC: simple-card-utils: set 0Hz to sysclk when shutdown"). This wasn't handled by the codec, instead it would set the FLL frequency to 0Hz which isn't working. Since we don't have any rate constraints just ignore this request. Fixes: 13409d27cb39 ("ASoC: wm8904: configure sysclk/FLL automatically") Signed-off-by: Michael Walle <michael@walle.cc> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20191122232532.22258-1-michael@walle.cc Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-27ASoC: rt5677: Fix build error without CONFIG_SPIYueHaibing1-0/+16
If CONFIG_SPI is n, SND_SOC_RT5677_SPI also is n, building fails: sound/soc/codecs/rt5677.o: In function `rt5677_irq': rt5677.c:(.text+0x2dbf): undefined reference to `rt5677_spi_hotword_detected' sound/soc/codecs/rt5677.o: In function `rt5677_dsp_work': rt5677.c:(.text+0x3709): undefined reference to `rt5677_spi_write' This adds stub helpers to fix this. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 461c623270e4 ("ASoC: rt5677: Load firmware via SPI using delayed work") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20191127082145.6100-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-27ASoC: SOF: topology: Fix unload for SAI/ESAIDaniel Baluta1-1/+3
Link unload now fails for ESAI/SAI DAIs with: "error: invalid DAI type 6" because DAI type is not properly handled. Fix this by correctly handling cases where type is ESAI or SAI. Fixes: a4eff5f86c9c5e7 ("ASoC: SOF: imx: Read ESAI parameters and send them to DSP") Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191126141606.21650-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-27ASoC: SOF: Intel: BYT: fix a copy/paste mistake in byt_dump()Keyon Jie1-9/+9
The shim registers in BYT/CHT/BSW are 64bits based, correct the copy/paste (from bdw.c where the shim registers are 32bits based) error in byt_dump(). Fixes: 3a9e204d4e36 ("ASoC: SOF: Intel: Add context data to any IPC timeout") Signed-off-by: Keyon Jie <yang.jie@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191126141533.21601-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-27ASoC: AMD: Enable clk in startup intead of hw_paramsYu-Hsuan Hsu1-32/+14
Some usages only call startup and shutdown without setting hw_params (e.g. arecord --dump-hw-params). If we don't enable clk in startup, it will cause ref count error because the clk will be disabled in shutdown. For this reason, we should move enabling clk from hw_params to startup. In addition, the hw_params is fixed in this driver(48000 rate, 2 channels, S16_LE format) so we don't need to change the clk rate after the hw_params is set. Signed-off-by: Yu-Hsuan Hsu <yuhsuan@chromium.org> Acked-by: Akshu Agrawal <akshu.agarawal@amd.com> Link: https://lore.kernel.org/r/20191126075424.80668-1-yuhsuan@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-25ASoC: rt5682: fix i2c arbitration lost issueShuming Fan1-0/+2
This patch modified the HW initial setting to fix i2c arbitration lost issue. Signed-off-by: Shuming Fan <shumingf@realtek.com> Link: https://lore.kernel.org/r/20191125091940.11953-1-shumingf@realtek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-22ASoC: DMI long name - avoid to add board name if matches with product nameJaroslav Kysela1-1/+2
Current code: LENOVO-20QE000VMC-ThinkPadX1Carbon7th-20QE000VMC With the patch: LENOVO-20QE000VMC-ThinkPadX1Carbon7th Signed-off-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20191120174435.30920-2-perex@perex.cz Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-22ASoC: improve the DMI long card code in asoc-coreJaroslav Kysela1-41/+25
Add append_dmi_string() function and make the code more readable. Signed-off-by: Jaroslav Kysela <perex@perex.cz> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191120174435.30920-1-perex@perex.cz Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-20ASoC: Fix Kconfig indentationKrzysztof Kozlowski2-17/+17
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191120133252.6365-1-krzk@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-20ASoC: soc-pcm: check symmetry before hw_paramsShengjiu Wang1-3/+5
This reverts commit 957ce0c6b8a1f (ASoC: soc-pcm: check symmetry after hw_params). That commit cause soc_pcm_params_symmetry can't take effect. cpu_dai->rate, cpu_dai->channels and cpu_dai->sample_bits are updated in the middle of soc_pcm_hw_params, so move soc_pcm_params_symmetry to the end of soc_pcm_hw_params is not a good solution, for judgement of symmetry in the function is always true. FIXME: According to the comments of that commit, I think the case described in the commit should disable symmetric_rates in Back-End, rather than changing the position of soc_pcm_params_symmetry. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1573555602-5403-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-20ASoC: pcm3168a: Update the RST gpio handling to align with documentationPeter Ujfalusi1-5/+15
The RST (reset-gpios) is low active so the driver must handle it accordingly. Add comments to explain clearly how the line is used. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20191120131753.6831-3-peter.ujfalusi@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-20ASoC: add control components managementJaroslav Kysela1-0/+13
This ASCII string can carry additional information about soundcard components or configuration. Add the possibility to set this string via the ASoC card. Signed-off-by: Jaroslav Kysela <perex@perex.cz> Cc: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20191119174933.25526-1-perex@perex.cz Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-19ASoC: soc-pcm: remove soc_pcm_private_free()Kuninori Morimoto2-18/+11
soc-topology adds extra dai_link by using snd_soc_add_dai_link(), and removes it by snd_soc_romove_dai_link(). This snd_soc_add/remove_dai_link() and/or its related functions are unbalanced before, and now, these are balance-uped. But, it finds the random operation issue, and it is reported by Pierre-Louis. When card was released, topology will call snd_soc_remove_dai_link() via (A). static void soc_cleanup_card_resources(struct snd_soc_card *card) { struct snd_soc_dai_link *link, *_link; /* This should be called before snd_card_free() */ (A) soc_remove_link_components(card); /* free the ALSA card at first; this syncs with pending operations */ if (card->snd_card) { (B) snd_card_free(card->snd_card); card->snd_card = NULL; } /* remove and free each DAI */ (X) soc_remove_link_dais(card); for_each_card_links_safe(card, link, _link) (C) snd_soc_remove_dai_link(card, link); ... } At (A), topology calls snd_soc_remove_dai_link(). Then topology rtd, and its related all data are freed. Next, (B) is called, and then, pcm->private_free = soc_pcm_private_free() is called. static void soc_pcm_private_free(struct snd_pcm *pcm) { struct snd_soc_pcm_runtime *rtd = pcm->private_data; /* need to sync the delayed work before releasing resources */ flush_delayed_work(&rtd->delayed_work); snd_soc_pcm_component_free(rtd); } Here, it gets rtd via pcm->private_data. But, topology related rtd are already freed at (A). Normal sound card has no damage, becase it frees rtd at (C). These are finalizing rtd related data. Thus, these should be called when rtd was freed, not sound card was freed. It is very natural and understandable. In other words, pcm->private_free = soc_pcm_private_free() is no longer needed. Extra issue is that there is zero chance to call soc_remove_dai() for topology related dai at (X). Because (A) removes rtd connection from card too, and, (X) is based on card connected rtd. This means, (X) need to be called before (C) (= for normal sound) and (A) (= for topology). Now, I want to focus this patch which is the reason why snd_card_free() = (B) is located there. commit 4efda5f2130da033aeedc5b3205569893b910de2 ("ASoC: Fix use-after-free at card unregistration") Original snd_card_free() was called last of this function. But moved to top to avoid use-after-free issue. The issue was happen at soc_pcm_free() which was pcm->private_free, today it is updated/renamed to soc_pcm_private_free(). In other words, (B) need to be called before (C) (= for normal sound) and (A) (= for topology), because it needs (not yet freed) rtd. But, (A) need to be called before (B), because it needs card->snd_card pointer. If we call flush_delayed_work() and snd_soc_pcm_component_free() (= same as soc_pcm_private_free()) when rtd was freed (= (C), (A)), there is no reason to call snd_card_free() at top of this function. It can be called end of this function, again. But, in such case, it will likely break unbind again, as Takashi-san reported. When unbind is performed in a busy state, the code may release still-in-use resources. At least we need to call snd_card_disconnect_sync() at the first place. The final code will be... static void soc_cleanup_card_resources(struct snd_soc_card *card) { struct snd_soc_dai_link *link, *_link; if (card->snd_card) (Z) snd_card_disconnect_sync(card->snd_card); (X) soc_remove_link_dais(card); (A) soc_remove_link_components(card); for_each_card_links_safe(card, link, _link) (C) snd_soc_remove_dai_link(card, link); ... if (card->snd_card) { (B) snd_card_free(card->snd_card); card->snd_card = NULL; } } To avoid release still-in-use resources, call snd_card_disconnect_sync() at (Z). (X) is needed for both non-topology and topology. topology removes rtd via (A), and non topology removes rtd via (C). snd_card_free() is no longer related to use-after-free issue. Thus, locating (B) is no problem. Fixes: df95a16d2a9626 ("ASoC: soc-core: fix RIP warning on card removal") Fixes: bc7a9091e5b927 ("ASoC: soc-core: add soc_unbind_dai_link()") Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/87o8xax88g.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-19ASoC: soc-component: tidyup snd_soc_pcm_component_new/free() parameterKuninori Morimoto2-7/+5
This patch uses rtd instead of pcm at snd_soc_pcm_component_new/free() parameter. This is prepare for dai_link remove bug fix on topology. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87pnhqx89j.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-18ASoC: wm_adsp: Expose mixer control APILi Xu2-1/+84
Expose mixer control API for reading and writing controls from the kernel. This API can be used by ALSA kernel drivers with ADSP support to read and write firmware-defined memory regions. Signed-off-by: Li Xu <li.xu@cirrus.com> Signed-off-by: David Rhodes <david.rhodes@cirrus.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/1573847653-17094-2-git-send-email-david.rhodes@cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-18ASoC: tlv320aic31xx: configure output common-mode voltageLucas Stach2-0/+53
The tlv320aic31xx devices allow to adjust the output common-mode voltage for best analog performance. The datasheet states that the common mode voltage should be set to be <= AVDD/2. This changes allows to configure the output common-mode voltage via a DT property. If the property is absent the voltage is automatically chosen as the highest voltage below/equal to AVDD/2. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Link: https://lore.kernel.org/r/20191118151207.28576-1-l.stach@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-18ASoC: SOF: Intel: Fix CFL and CML FW nocodec binary names.Liam Girdwood1-4/+4
The manifest information is different between CNL, CML and CFL platforms hence we need to load different files. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191111222901.19892-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-18ASoC: pcm3168a: Add support for optional RST gpio handlingPeter Ujfalusi1-4/+34
In case the RST line is connected to a GPIO line it needs to be pulled high when the driver probes to be able to use the codec. Add support also for cases when more than one codec is is controlled by the same GPIO line by requesting the gpio with GPIOD_FLAGS_BIT_NONEXCLUSIVE. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20191113124734.27984-3-peter.ujfalusi@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-18ASoC: wm5100: add missed pm_runtime_disableChuhong Yuan1-0/+2
The driver forgets to call pm_runtime_disable in remove and probe failure. Add the calls to fix it. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20191118073707.28298-1-hslester96@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-18ASoC: wm2200: add missed operations in remove and probe failureChuhong Yuan1-0/+5
This driver misses calls to pm_runtime_disable and regulator_bulk_disable in remove and a call to free_irq in probe failure. Add the calls to fix it. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Link: https://lore.kernel.org/r/20191118073633.28237-1-hslester96@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-18ASoC: qcom: q6asm-dai: add support to flac decoderVinod Koul1-1/+34
Qualcomm DSPs also support the flac decoder, so add support for FLAC decoder and convert the snd_dec_flac params to qdsp format. Co-developed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20191115102705.649976-4-vkoul@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-18ASoC: qcom: q6asm: add support to flac configSrinivas Kandagatla2-0/+70
Qualcomm DSPs expect flac config to be set for flac decoders, so add the API to program the flac config to the DSP Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20191115102705.649976-3-vkoul@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-18ASoC: rt5677: rt5677_check_hotword() can be statickbuild test robot1-1/+1
Fixes: 21c00e5df439 ("ASoC: rt5677: Enable jack detect while DSP is running") Signed-off-by: kbuild test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20191114153304.n4pyix7qadu76tx4@4978f4969bb8 Signed-off-by: Mark Brown <broonie@kernel.org>