- 10 Dec, 2019 3 commits
-
-
Daniel Baluta authored
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.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
Dragos Tarcatu authored
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.comSigned-off-by:
-
Dragos Tarcatu authored
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:
-
- 09 Dec, 2019 1 commit
-
-
Curtis Malainey authored
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.orgSigned-off-by:
-
- 04 Dec, 2019 2 commits
-
-
Hans de Goede authored
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:
-
Curtis Malainey authored
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:
Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20191203173007.46504-1-cujomalainey@chromium.orgSigned-off-by:
-
- 03 Dec, 2019 1 commit
-
-
YueHaibing authored
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:
-
- 27 Nov, 2019 8 commits
-
-
Tzung-Bi Shih authored
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.comReviewed-by:
-
Tzung-Bi Shih authored
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 authored
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:
-
Michael Walle authored
The simple-card tries to signal the codec to disable rate constraints, see commit 2458adb8 ("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: 13409d27 ("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.ccSigned-off-by:
-
YueHaibing authored
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:
-
Daniel Baluta authored
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: a4eff5f8 ("ASoC: SOF: imx: Read ESAI parameters and send them to DSP") Signed-off-by:
-
Keyon Jie authored
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: 3a9e204d ("ASoC: SOF: Intel: Add context data to any IPC timeout") Signed-off-by:
Keyon Jie <yang.jie@linux.intel.com> Signed-off-by:
-
Yu-Hsuan Hsu authored
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.orgSigned-off-by:
-
- 25 Nov, 2019 1 commit
-
-
Shuming Fan authored
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.comSigned-off-by:
-
- 22 Nov, 2019 2 commits
-
-
Jaroslav Kysela authored
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.czReviewed-by:
-
Jaroslav Kysela authored
Add append_dmi_string() function and make the code more readable. Signed-off-by:
-
- 20 Nov, 2019 6 commits
-
-
Krzysztof Kozlowski authored
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:
-
Shengjiu Wang authored
This reverts commit 957ce0c6 (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.comSigned-off-by:
-
Peter Ujfalusi authored
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.comSigned-off-by:
-
Peter Ujfalusi authored
Use the standard name for the gpion in DT: reset-gpios Document that the RST line is low active and update the example accordingly. Signed-off-by:
-
Tzung-Bi Shih authored
Add SND_SOC_BYTES_E to accept getter and putter. Signed-off-by:
-
Jaroslav Kysela authored
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:
-
- 19 Nov, 2019 2 commits
-
-
Kuninori Morimoto authored
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 4efda5f2 ("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: df95a16d ("ASoC: soc-core: fix RIP warning on card removal") Fixes: bc7a9091 ("ASoC: soc-core: add soc_unbind_dai_link()") Reported-by: -
Kuninori Morimoto authored
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:
-
- 18 Nov, 2019 11 commits
-
-
Li Xu authored
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:
-
Lucas Stach authored
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.deSigned-off-by:
-
Liam Girdwood authored
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:
-
Peter Ujfalusi authored
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 authored
On boards where the RST line is not pulled up, but it is connected to a GPIO line this property must present in order to be able to enable the codec. Signed-off-by:
-
Chuhong Yuan authored
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:
-
Chuhong Yuan authored
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:
-
Vinod Koul authored
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:
Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20191115102705.649976-4-vkoul@kernel.orgSigned-off-by:
-
Srinivas Kandagatla authored
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:
-
Vinod Koul authored
The current design of sending codec parameters assumes that decoders will have parsers so they can parse the encoded stream for parameters and configure the decoder. But this assumption may not be universally true and we know some DSPs which do not contain the parsers so additional parameters are required to be passed. So add these parameters starting with FLAC decoder. The size of snd_codec_options is still 120 bytes after this change (due to this being a union) Co-developed-by:
-
kbuild test robot authored
Fixes: 21c00e5d ("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@4978f4969bb8Signed-off-by:
-
- 15 Nov, 2019 3 commits
-
-
Peter Ujfalusi authored
dma_request_slave_channel_reason() is: #define dma_request_slave_channel_reason(dev, name) \ dma_request_chan(dev, name) Signed-off-by:
-
Peter Ujfalusi authored
dma_request_slave_channel_reason() is: #define dma_request_slave_channel_reason(dev, name) \ dma_request_chan(dev, name) Signed-off-by:
-
Kuninori Morimoto authored
soc_cleanup_card_resources() will call card->remove(), but it should be called if card->probe() or card->late_probe() are called. snd_soc_bind_card() might be error before calling card->probe() / card->late_probe(). In that time, card->remove() will be called. This patch adds card_probed parameter to judge it. Fixes: bfce78a5 ("ASoC: soc-core: tidyup soc_init_dai_link()") Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/87o8xg4ltr.wl-kuninori.morimoto.gx@renesas.comSigned-off-by:
-
