- 28 Apr, 2020 1 commit
-
-
Xiyu Yang authored
davinci_mcasp_get_dma_type() invokes dma_request_chan(), which returns a reference of the specified dma_chan object to "chan" with increased refcnt. When davinci_mcasp_get_dma_type() returns, local variable "chan" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of davinci_mcasp_get_dma_type(). When chan device is NULL, the function forgets to decrease the refcnt increased by dma_request_chan(), causing a refcnt leak. Fix this issue by calling dma_release_channel() when chan device is NULL. Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn> Signed-off-by: Xin Tan <tanxin.ctf@gmail.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/1587818916-38730-1-git-send-email-xiyuyang19@fudan.edu.cnSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 27 Apr, 2020 1 commit
-
-
Shengjiu Wang authored
Disable exception interrupt before scheduling tasklet, otherwise if the tasklet isn't handled immediately, there will be endless xrun interrupt. Fixes: 7ccafa2b ("ASoC: fsl_esai: recover the channel swap after xrun") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Acked-by: Nicolin Chen <nicoleotsuka@gmail.com> Link: https://lore.kernel.org/r/a8f2ad955aac9e52587beedc1133b3efbe746895.1587968824.git.shengjiu.wang@nxp.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 24 Apr, 2020 1 commit
-
-
Shengjiu Wang authored
Previously CLOCKING2 is set as a volatile register, but cause issue at suspend & resume, that some bits of CLOCKING2 is not restored at resume, for example SYSCLK_SRC bits, then the output clock is wrong. The volatile property is caused by CLASSD_CLK_DIV bits, which are controlled by the chip itself. But the datasheet claims these are read only and protected by the security key, and they are not read by the driver at all. So it should be safe to change CLOCKING2 to be non-volatile. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/6d25d5b36d4b9aeb8655b5e947dad52214e34177.1587693523.git.shengjiu.wang@nxp.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 22 Apr, 2020 1 commit
-
-
Mark Brown authored
Merge tag 'tegra-for-5.7-asoc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into asoc-5.7 ASoC: tegra: Fixes for v5.7-rc3 This contains a couple of fixes that are needed to properly reconfigure the audio clocks on older Tegra devices.
-
- 21 Apr, 2020 5 commits
-
-
Sowjanya Komatineni authored
Tegra PMC clock clk_out_1 is dedicated for audio mclk from Tegra30 through Tegra210 and currently Tegra clock driver keeps the audio mclk enabled. With the move of PMC clocks from clock driver into pmc driver, audio mclk enable from clock driver is removed and this should be taken care of by the audio driver. tegra_asoc_utils_init() calls tegra_asoc_utils_set_rate() and audio mclk rate configuration is not needed during init and the rate is actually set during the ->hw_params() callback. So, this patch removes tegra_asoc_utils_set_rate() call and just leaves the audio mclk enabled. Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Tested-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Sowjanya Komatineni authored
Tegra PMC clock clk_out_1 is dedicated for audio mclk from Tegra30 through Tegra210 and currently Tegra clock driver does the initial parent configuration for audio mclk and keeps it enabled by default. With the move of PMC clocks from clock driver into PMC driver, audio clocks parent configuration can be specified through the device tree using assigned-clock-parents property and audio mclk control should be taken care of by the audio driver. This patch has implementation for parent configuration when default parent configuration through assigned-clock-parents property is not specified in the device tree. Tested-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Sameer Pujar <spujar@nvidia.com> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Sowjanya Komatineni authored
Tegra clk_out_1, clk_out_2, and clk_out_3 are part of PMC block and these clocks are moved from the clock driver to PMC driver with PMC as a provider for these clocks. Update bindings document to use PMC as clock provider for clk_out_2 and change ID to PMC clock ID. Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Sowjanya Komatineni authored
tegra_asoc_utils uses clk_get() to get the clock and clk_put() to free them explicitly. This patch updates it to use device managed resource API devm_clk_get() so the clock will be automatically released and freed when the device is unbound and removes tegra_asoc_utils_fini() as its no longer needed. Tested-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Sameer Pujar <spujar@nvidia.com> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
-
Shengjiu Wang authored
After suspend & resume, wm8960_hw_params may be called when bias_level is not SND_SOC_BIAS_ON, then wm8960_configure_clocking is not called. But if sample rate is changed at that time, then the output clock rate will be not correct. So judgement of bias_level is SND_SOC_BIAS_ON in wm8960_hw_params is not necessary and it causes above issue. Fixes: 3176bf2d ("ASoC: wm8960: update pll and clock setting function") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/1587468525-27514-1-git-send-email-shengjiu.wang@nxp.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 20 Apr, 2020 8 commits
-
-
YueHaibing authored
sound/soc/codecs/wm8900.o: In function `wm8900_i2c_probe': wm8900.c:(.text+0xa36): undefined reference to `__devm_regmap_init_i2c' sound/soc/codecs/wm8900.o: In function `wm8900_modinit': wm8900.c:(.init.text+0xb): undefined reference to `i2c_register_driver' sound/soc/codecs/wm8900.o: In function `wm8900_exit': wm8900.c:(.exit.text+0x8): undefined reference to `i2c_del_driver' sound/soc/codecs/wm8988.o: In function `wm8988_i2c_probe': wm8988.c:(.text+0x857): undefined reference to `__devm_regmap_init_i2c' sound/soc/codecs/wm8988.o: In function `wm8988_modinit': wm8988.c:(.init.text+0xb): undefined reference to `i2c_register_driver' sound/soc/codecs/wm8988.o: In function `wm8988_exit': wm8988.c:(.exit.text+0x8): undefined reference to `i2c_del_driver' sound/soc/codecs/wm8995.o: In function `wm8995_i2c_probe': wm8995.c:(.text+0x1c4f): undefined reference to `__devm_regmap_init_i2c' sound/soc/codecs/wm8995.o: In function `wm8995_modinit': wm8995.c:(.init.text+0xb): undefined reference to `i2c_register_driver' sound/soc/codecs/wm8995.o: In function `wm8995_exit': wm8995.c:(.exit.text+0x8): undefined reference to `i2c_del_driver' Add SND_SOC_I2C_AND_SPI dependency to fix this. Fixes: ea00d952 ("ASoC: Use imply for SND_SOC_ALL_CODECS") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200420125343.20920-1-yuehaibing@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Mark Brown authored
Merge series "ASoC: rsnd: multi-SSI setup fixes" from Matthias Blankertz <matthias.blankertz@cetitec.com>: Fix rsnd_dai_call() operations being performed twice for the master SSI in multi-SSI setups, and fix the rsnd_ssi_stop operation for multi-SSI setups. The only visible effect of these issues was some "status check failed" spam when the rsnd_ssi_stop was called, but overall the code is cleaner now, and some questionable writes to the SSICR register which did not lead to any observable misbehaviour but were contrary to the datasheet are fixed. Mark: The first patch kind of reverts my "ASoC: rsnd: Fix parent SSI start/stop in multi-SSI mode" from a few days ago and achieves the same effect in a simpler fashion, if you would prefer a clean patch series based on v5.6 drop me a note. Greetings, Matthias Matthias Blankertz (2): ASoC: rsnd: Don't treat master SSI in multi SSI setup as parent ASoC: rsnd: Fix "status check failed" spam for multi-SSI sound/soc/sh/rcar/ssi.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) base-commit: 15a5760c -- 2.26.1
-
Mark Brown authored
Merge series "ASoC: meson: fix codec-to-codec link setup" from Jerome Brunet <jbrunet@baylibre.com>: This patchset fixes the problem reported by Marc in this thread [0] The problem was due to an error in the meson card drivers which had the "no_pcm" dai_link property set on codec-to-codec links [0]: https://lore.kernel.org/r/20200417122732.GC5315@sirena.org.uk Jerome Brunet (2): ASoC: meson: axg-card: fix codec-to-codec link setup ASoC: meson: gx-card: fix codec-to-codec link setup sound/soc/meson/axg-card.c | 4 +++- sound/soc/meson/gx-card.c | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) -- 2.25.2
-
Gyeongtaek Lee authored
snd_soc_dapm_kcontrol widget which is created by autodisable control should contain correct on_val, mask and shift because it is set when the widget is powered and changed value is applied on registers by following code in dapm_seq_run_coalesced(). mask |= w->mask << w->shift; if (w->power) value |= w->on_val << w->shift; else value |= w->off_val << w->shift; Shift on the mask in dapm_kcontrol_data_alloc() is removed to prevent double shift. And, on_val in dapm_kcontrol_set_value() is modified to get correct value in the dapm_seq_run_coalesced(). Signed-off-by: Gyeongtaek Lee <gt82.lee@samsung.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/000001d61537$b212f620$1638e260$@samsung.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Matthias Blankertz authored
Fix the rsnd_ssi_stop function to skip disabling the individual SSIs of a multi-SSI setup, as the actual stop is performed by rsnd_ssiu_stop_gen2 - the same logic as in rsnd_ssi_start. The attempt to disable these SSIs was harmless, but caused a "status check failed" message to be printed for every SSI in the multi-SSI setup. The disabling of interrupts is still performed, as they are enabled for all SSIs in rsnd_ssi_init, but care is taken to not accidentally set the EN bit for an SSI where it was not set by rsnd_ssi_start. Signed-off-by: Matthias Blankertz <matthias.blankertz@cetitec.com> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20200417153017.1744454-3-matthias.blankertz@cetitec.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Matthias Blankertz authored
The master SSI of a multi-SSI setup was attached both to the RSND_MOD_SSI slot and the RSND_MOD_SSIP slot of the rsnd_dai_stream. This is not correct wrt. the meaning of being "parent" in the rest of the SSI code, where it seems to indicate an SSI that provides clock and word sync but is not transmitting/receiving audio data. Not treating the multi-SSI master as parent allows removal of various special cases to the rsnd_ssi_is_parent conditions introduced in commit a09fb3f2 ("ASoC: rsnd: Fix parent SSI start/stop in multi-SSI mode"). It also fixes the issue that operations performed via rsnd_dai_call() were performed twice for the master SSI. This caused some "status check failed" spam when stopping a multi-SSI stream as the driver attempted to stop the master SSI twice. Signed-off-by: Matthias Blankertz <matthias.blankertz@cetitec.com> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20200417153017.1744454-2-matthias.blankertz@cetitec.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Jerome Brunet authored
Since the addition of commit 9b5db059 ("ASoC: soc-pcm: dpcm: Only allow playback/capture if supported"), meson-axg cards which have codec-to-codec links fail to init and Oops. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000128 Internal error: Oops: 96000044 [#1] PREEMPT SMP CPU: 3 PID: 1582 Comm: arecord Not tainted 5.7.0-rc1 pc : invalidate_paths_ep+0x30/0xe0 lr : snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8 Call trace: invalidate_paths_ep+0x30/0xe0 snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8 dpcm_path_get+0x38/0xd0 dpcm_fe_dai_open+0x70/0x920 snd_pcm_open_substream+0x564/0x840 snd_pcm_open+0xfc/0x228 snd_pcm_capture_open+0x4c/0x78 snd_open+0xac/0x1a8 ... While this error was initially reported the axg-card type, it also applies to the gx-card type. While initiliazing the links, ASoC treats the codec-to-codec links of this card type as a DPCM backend. This error eventually leads to the Oops. Most of the card driver code is shared between DPCM backends and codec-to-codec links. The property "no_pcm" marking DCPM BE was left set on codec-to-codec links, leading to this problem. This commit fixes that. Fixes: e37a0c31 ("ASoC: meson: gx: add sound card support") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20200420114511.450560-3-jbrunet@baylibre.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Jerome Brunet authored
Since the addition of commit 9b5db059 ("ASoC: soc-pcm: dpcm: Only allow playback/capture if supported"), meson-axg cards which have codec-to-codec links fail to init and Oops: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000128 Internal error: Oops: 96000044 [#1] PREEMPT SMP CPU: 3 PID: 1582 Comm: arecord Not tainted 5.7.0-rc1 pc : invalidate_paths_ep+0x30/0xe0 lr : snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8 Call trace: invalidate_paths_ep+0x30/0xe0 snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8 dpcm_path_get+0x38/0xd0 dpcm_fe_dai_open+0x70/0x920 snd_pcm_open_substream+0x564/0x840 snd_pcm_open+0xfc/0x228 snd_pcm_capture_open+0x4c/0x78 snd_open+0xac/0x1a8 ... While initiliazing the links, ASoC treats the codec-to-codec links of this card type as a DPCM backend. This error eventually leads to the Oops. Most of the card driver code is shared between DPCM backends and codec-to-codec links. The property "no_pcm" marking DCPM BE was left set on codec-to-codec links, leading to this problem. This commit fixes that. Fixes: 0a8f1117 ("ASoC: meson: axg-card: add basic codec-to-codec link support") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20200420114511.450560-2-jbrunet@baylibre.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 17 Apr, 2020 2 commits
-
-
Pierre-Louis Bossart authored
Major regressions were detected by SOF CI on CherryTrail and Broadwell: [ 25.705750] SSP2-Codec: ASoC: no backend playback stream [ 27.923378] SSP2-Codec: ASoC: no users playback at close - state This is root-caused to the introduction of the DAI capability checks with snd_soc_dai_stream_valid(). Its use in soc-pcm.c makes it a requirement for all DAIs to report at least a non-zero min_channels field. For some reason the SSP structures used for SKL+ did provide this information but legacy platforms didn't. Fixes: 9b5db059 ("ASoC: soc-pcm: dpcm: Only allow playback/capture if supported") Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20200417172014.11760-1-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Olivier Moysan authored
pcm config must be set before snd_dmaengine_pcm_register() call. Fixes: 0d6defc7 ("ASoC: stm32: sai: manage rebind issue") Signed-off-by: Olivier Moysan <olivier.moysan@st.com> Link: https://lore.kernel.org/r/20200417142122.10212-1-olivier.moysan@st.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 16 Apr, 2020 4 commits
-
-
Mark Brown authored
Merge series "ASoC: rsnd: Fixes for multichannel HDMI audio output" from Matthias Blankertz <matthias.blankertz@cetitec.com>: This fixes two issues in the snd-soc-rcar driver blocking multichannel HDMI audio out: The parent SSI in a multi-SSI configuration is not correctly set up and started, and the SSI->HDMI channel mapping is wrong. With these patches, the following device tree snippet can be used on an r8a7795-based platform (Salvator-X) to enable multichannel HDMI audio on HDMI0: rsnd_port1: port@1 { rsnd_endpoint1: endpoint { remote-endpoint = <&dw_hdmi0_snd_in>; dai-format = "i2s"; bitclock-master = <&rsnd_endpoint1>; frame-master = <&rsnd_endpoint1>; playback = <&ssi0 &ssi1 &ssi2 &ssi9>; }; }; With a capable receiver attached, all of 2ch (stereo), 6ch (e.g. 5.1) and 8ch audio output should work. Matthias Blankertz (2): ASoC: rsnd: Fix parent SSI start/stop in multi-SSI mode ASoC: rsnd: Fix HDMI channel mapping for multi-SSI mode sound/soc/sh/rcar/ssi.c | 8 ++++---- sound/soc/sh/rcar/ssiu.c | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) base-commit: 7111951b -- 2.26.0
-
Amadeusz Sławiński authored
If we don't find any pcm, pcm will point at address at an offset from the the list head and not a meaningful structure. Fix this by returning correct pcm if found and NULL if not. Found with coccinelle. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Link: https://lore.kernel.org/r/20200415162849.308-1-amadeuszx.slawinski@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Matthias Blankertz authored
The HDMI?_SEL register maps up to four stereo SSI data lanes onto the sdata[0..3] inputs of the HDMI output block. The upper half of the register contains four blocks of 4 bits, with the most significant controlling the sdata3 line and the least significant the sdata0 line. The shift calculation has an off-by-one error, causing the parent SSI to be mapped to sdata3, the first multi-SSI child to sdata0 and so forth. As the parent SSI transmits the stereo L/R channels, and the HDMI core expects it on the sdata0 line, this causes no audio to be output when playing stereo audio on a multichannel capable HDMI out, and multichannel audio has permutated channels. Fix the shift calculation to map the parent SSI to sdata0, the first child to sdata1 etc. Signed-off-by: Matthias Blankertz <matthias.blankertz@cetitec.com> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20200415141017.384017-3-matthias.blankertz@cetitec.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Matthias Blankertz authored
The parent SSI of a multi-SSI setup must be fully setup, started and stopped since it is also part of the playback/capture setup. So only skip the SSI (as per commit 203cdf51 ("ASoC: rsnd: SSI parent cares SWSP bit") and commit 597b046f ("ASoC: rsnd: control SSICR::EN correctly")) if the SSI is parent outside of a multi-SSI setup. Signed-off-by: Matthias Blankertz <matthias.blankertz@cetitec.com> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20200415141017.384017-2-matthias.blankertz@cetitec.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 15 Apr, 2020 5 commits
-
-
Pierre-Louis Bossart authored
On Baytrail/Cherrytrail, the Atom/SST driver fails miserably: [ 9.741953] intel_sst_acpi 80860F28:00: FW Version 01.0c.00.01 [ 9.832992] intel_sst_acpi 80860F28:00: FW sent error response 0x40034 [ 9.833019] intel_sst_acpi 80860F28:00: FW alloc failed ret -4 [ 9.833028] intel_sst_acpi 80860F28:00: sst_get_stream returned err -5 [ 9.833033] sst-mfld-platform sst-mfld-platform: ASoC: DAI prepare error: -5 [ 9.833037] Baytrail Audio Port: ASoC: prepare FE Baytrail Audio Port failed [ 9.853942] intel_sst_acpi 80860F28:00: FW sent error response 0x40034 [ 9.853974] intel_sst_acpi 80860F28:00: FW alloc failed ret -4 [ 9.853984] intel_sst_acpi 80860F28:00: sst_get_stream returned err -5 [ 9.853990] sst-mfld-platform sst-mfld-platform: ASoC: DAI prepare error: -5 [ 9.853994] Baytrail Audio Port: ASoC: prepare FE Baytrail Audio Port failed Commit b56be800 ("ASoC: soc-pcm: call snd_soc_dai_startup()/shutdown() once") was the initial problematic commit. Commit 1ba616bd ("ASoC: soc-dai: fix DAI startup/shutdown sequence") was an attempt to fix things but it does not work on Baytrail, reverting all changes seems necessary for now. Fixes: 1ba616bd ("ASoC: soc-dai: fix DAI startup/shutdown sequence") Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200415030437.23803-1-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Amadeusz Sławiński authored
As done in already existing cases, we should use le32_to_cpu macro while accessing hdr->magic. Found with sparse. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Link: https://lore.kernel.org/r/20200415162435.31859-2-amadeuszx.slawinski@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Stephan Gerhold authored
For some reason, the MI2S DAIs do not have channels_min/max defined. This means that snd_soc_dai_stream_valid() returns false, i.e. the DAIs have neither valid playback nor capture stream. It's quite surprising that this ever worked correctly, but in 5.7-rc1 this is now failing badly: :) Commit 0e9cf4c4 ("ASoC: pcm: check if cpu-dai supports a given stream") introduced a check for snd_soc_dai_stream_valid() before calling hw_params(), which means that the q6i2s_hw_params() function was never called, eventually resulting in: qcom-q6afe aprsvc:q6afe:4:4: no line is assigned ... even though "qcom,sd-lines" is set in the device tree. Commit 9b5db059 ("ASoC: soc-pcm: dpcm: Only allow playback/capture if supported") now even avoids creating PCM devices if the stream is not supported, which means that it is failing even earlier with e.g.: Primary MI2S: ASoC: no backend playback stream Avoid all that trouble by adding channels_min/max for the MI2S DAIs. Fixes: 24c4cbcf ("ASoC: qdsp6: q6afe: Add q6afe dai driver") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200415150050.616392-1-stephan@gerhold.netSigned-off-by: Mark Brown <broonie@kernel.org>
-
Stephan Gerhold authored
At the moment, PCM devices for DPCM are only created based on the dpcm_playback/capture parameters of the DAI link, without considering if the CPU/FE DAI is actually capable of playback/capture. Normally the dpcm_playback/capture parameter should match the capabilities of the CPU DAI. However, there is no way to set that parameter from the device tree (e.g. with simple-audio-card or qcom sound cards). dpcm_playback/capture are always both set to 1. This causes problems when the CPU DAI does only support playback or capture. Attemting to open that PCM device with an unsupported stream type then results in a null pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000128 Internal error: Oops: 96000044 [#1] PREEMPT SMP CPU: 3 PID: 1582 Comm: arecord Not tainted 5.7.0-rc1 pc : invalidate_paths_ep+0x30/0xe0 lr : snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8 Call trace: invalidate_paths_ep+0x30/0xe0 snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8 dpcm_path_get+0x38/0xd0 dpcm_fe_dai_open+0x70/0x920 snd_pcm_open_substream+0x564/0x840 snd_pcm_open+0xfc/0x228 snd_pcm_capture_open+0x4c/0x78 snd_open+0xac/0x1a8 ... ... because the DAI playback/capture_widget is not set in that case. We could add checks there to fix the problem (maybe we should anyway), but much easier is to not expose the device as playback/capture in the first place. Attemting to use that device would always fail later anyway. Add checks for snd_soc_dai_stream_valid() to the DPCM case to avoid exposing playback/capture if it is not supported. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200415104928.86091-1-stephan@gerhold.netSigned-off-by: Mark Brown <broonie@kernel.org>
-
Sebastian Reichel authored
As mentioned slightly out of patch context in the code, there is no reset routine for the chip. On boards where the chip is supplied by a fixed regulator, it might not even be resetted during (e.g. watchdog) reboot and can be in any state. If the device is probed with VAG enabled, the driver's probe routine will generate a loud pop sound when ANA_POWER is being programmed. Avoid this by properly disabling just the VAG bit and waiting the required power down time. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Fabio Estevam <festivem@gmail.com> Link: https://lore.kernel.org/r/20200414181140.145825-1-sebastian.reichel@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 14 Apr, 2020 12 commits
-
-
Johan Jonker authored
In the old txt situation we add/describe only properties that are used by the driver/hardware itself. With yaml it also filters things in a node that are used by other drivers like 'power-domains' for rk3399, so add it to 'rockchip-i2s.yaml'. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200324094149.6904-3-jbx6244@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200409181311.30247-1-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Srinivas Kandagatla authored
WSA881x works in PDM mode so the wordlength is fixed, which also makes the only field "WordLength" in DPN_BlockCtrl1 register a read-only. Writing to this register will throw up errors with Qualcomm Controller. So use ro_blockctrl1_reg flag to mark this field as read-only so that core will not write to this register. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20200414110347.23829-1-srinivas.kandagatla@linaro.orgSigned-off-by: Mark Brown <broonie@kernel.org>
-
Bjorn Andersson authored
All error paths in qcom_snd_parse_of() prints more specific error messages, so silence the one in apq8096_platform_probe() and sdm845_snd_platform_probe() to avoid spamming the kernel log. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200406003229.2354631-1-bjorn.andersson@linaro.orgSigned-off-by: Mark Brown <broonie@kernel.org>
-
Sebastian Fricke authored
Message logged by 'dev_xxx()' or 'pr_xxx()' should end with a '\n'. Fixes: 3e086edf("ASoC: stm32: add SAI drivers") Signed-off-by: Sebastian Fricke <sebastian.fricke.linux@gmail.com> Link: https://lore.kernel.org/r/20200413042952.7675-1-sebastian.fricke.linux@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
This helper is adding very little both it and is one caller are very small functions simply combine the two. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200409181209.30130-3-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
Move the error message into snd_soc_dapm_new_dai from dapm_connect_dai_pair, since the two copies are almost identical and are the only callers. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200409181209.30130-2-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Johan Jonker authored
In the old txt situation we add/describe only properties that are used by the driver/hardware itself. With yaml it also filters things in a node that are used by other drivers like 'power-domains' for rk3399, so add it to 'rockchip-spdif.yaml'. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200404115225.4314-3-jbx6244@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Johan Jonker authored
'#sound-dai-cells' is required to properly interpret the list of DAI specified in the 'sound-dai' property, so add them to 'rockchip-spdif.yaml' Signed-off-by: Johan Jonker <jbx6244@gmail.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200404115225.4314-2-jbx6244@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Johan Jonker authored
Current dts files with 'spdif' nodes are manually verified. In order to automate this process rockchip-spdif.txt has to be converted to yaml. Also rk3188.dtsi, rk3288.dtsi use an extra fallback string, so change this in the documentation. Changed: "rockchip,rk3188-spdif", "rockchip,rk3066-spdif" "rockchip,rk3288-spdif", "rockchip,rk3066-spdif" Signed-off-by: Johan Jonker <jbx6244@gmail.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200404115225.4314-1-jbx6244@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Jason Yan authored
Fix the following gcc warning: sound/soc/intel/common/soc-acpi-intel-cml-match.c:116:45: warning: ‘rt1308_2_adr’ defined but not used [-Wunused-const-variable=] static const struct snd_soc_acpi_adr_device rt1308_2_adr[] = { ^~~~~~~~~~~~ Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20200410081117.21319-2-yanaijie@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Jason Yan authored
Fix the following gcc warning: sound/soc/intel/common/soc-acpi-intel-icl-match.c:90:45: warning: ‘rt1308_2_adr’ defined but not used [-Wunused-const-variable=] static const struct snd_soc_acpi_adr_device rt1308_2_adr[] = { ^~~~~~~~~~~~ Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200410081117.21319-1-yanaijie@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>
-