- 20 Apr, 2020 1 commit
-
-
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:
-
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:
-
- 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:
-
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:
-
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:
-
- 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:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200415030437.23803-1-pierre-louis.bossart@linux.intel.comSigned-off-by:
-
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:
-
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:
-
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: -
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:
-
- 14 Apr, 2020 16 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:
-
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:
-
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:
Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20200414110347.23829-1-srinivas.kandagatla@linaro.orgSigned-off-by:
-
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:
-
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:
-
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 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:
-
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 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 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:
-
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:
-
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: -
Akshu Agrawal authored
RT5682 buttons were incorrectly mapped. Signed-off-by:
Akshu Agrawal <akshu.agrawal@amd.com> Link: https://lore.kernel.org/r/20200414113527.13532-1-akshu.agrawal@amd.comSigned-off-by:
-
Philipp Puschmann authored
If probe fails after enabling the regulators regulator_put is called for each supply without having them disabled before. This produces some warnings like WARNING: CPU: 0 PID: 90 at drivers/regulator/core.c:2044 _regulator_put.part.0+0x154/0x15c [<c010f7a8>] (unwind_backtrace) from [<c010c544>] (show_stack+0x10/0x14) [<c010c544>] (show_stack) from [<c012b640>] (__warn+0xd0/0xf4) [<c012b640>] (__warn) from [<c012b9b4>] (warn_slowpath_fmt+0x64/0xc4) [<c012b9b4>] (warn_slowpath_fmt) from [<c04c4064>] (_regulator_put.part.0+0x154/0x15c) [<c04c4064>] (_regulator_put.part.0) from [<c04c4094>] (regulator_put+0x28/0x38) [<c04c4094>] (regulator_put) from [<c04c40cc>] (regulator_bulk_free+0x28/0x38) [<c04c40cc>] (regulator_bulk_free) from [<c0579b2c>] (release_nodes+0x1d0/0x22c) [<c0579b2c>] (release_nodes) from [<c05756dc>] (really_probe+0x108/0x34c) [<c05756dc>] (really_probe) from [<c0575aec>] (driver_probe_device+0xb8/0x16c) [<c0575aec>] (driver_probe_device) from [<c0575d40>] (device_driver_attach+0x58/0x60) [<c0575d40>] (device_driver_attach) from [<c0575da0>] (__driver_attach+0x58/0xcc) [<c0575da0>] (__driver_attach) from [<c0573978>] (bus_for_each_dev+0x78/0xc0) [<c0573978>] (bus_for_each_dev) from [<c0574b5c>] (bus_add_driver+0x188/0x1e0) [<c0574b5c>] (bus_add_driver) from [<c05768b0>] (driver_register+0x74/0x108) [<c05768b0>] (driver_register) from [<c061ab7c>] (i2c_register_driver+0x3c/0x88) [<c061ab7c>] (i2c_register_driver) from [<c0102df8>] (do_one_initcall+0x58/0x250) [<c0102df8>] (do_one_initcall) from [<c01a91bc>] (do_init_module+0x60/0x244) [<c01a91bc>] (do_init_module) from [<c01ab5a4>] (load_module+0x2180/0x2540) [<c01ab5a4>] (load_module) from [<c01abbd4>] (sys_finit_module+0xd0/0xe8) [<c01abbd4>] (sys_finit_module) from [<c01011e0>] (__sys_trace_return+0x0/0x20) Fixes: 3fd6e7d9 (ASoC: tas571x: New driver for TI TAS571x power amplifiers) Signed-off-by:
Philipp Puschmann <p.puschmann@pironex.de> Link: https://lore.kernel.org/r/20200414112754.3365406-1-p.puschmann@pironex.deSigned-off-by:
-
Charles Keepax authored
Refactoring was done to factor out the linking of DAI widgets into a helper function, dapm_add_valid_dai_widget. However when this was done, a regression was introduced for CODEC to CODEC links. It was over looked that the playback and capture variables persisted across all CODEC DAIs being processed, which ensured that the special DAI widget that is added for CODEC to CODEC links was only created once. This bug causes kernel panics during DAPM shutdown. To stick with the spirit of the original refactoring whilst fixing the issue, variables to hold the DAI widgets are added to snd_soc_dai_link. Furthermore the dapm_add_valid_dai_widget function is renamed to dapm_connect_dai_pair, the function only adds DAI widgets in the CODEC to CODEC case and its primary job is to add routes connecting two DAI widgets, making the original name quite misleading. Fixes: 6c4b13b5 ("ASoC: Add dapm_add_valid_dai_widget helper") Signed-off-by:
-
Krzysztof Kozlowski authored
Commit 450312b6 ("ASoC: soc-core: remove DAI suspend/resume") removed the DAI side suspend/resume hooks and switched entirely to component suspend/resume. However the Samsung SoC s3c-i2s-v2 driver was not updated. Move the suspend/resume hooks from s3c-i2s-v2.c to s3c2412-i2s.c while changing dai to component which allows to keep the struct snd_soc_component_driver const. This fixes build errors: sound/soc/samsung/s3c-i2s-v2.c: In function ‘s3c_i2sv2_register_component’: sound/soc/samsung/s3c-i2s-v2.c:730:9: error: ‘struct snd_soc_dai_driver’ has no member named ‘suspend’ dai_drv->suspend = s3c2412_i2s_suspend; Reported-by:
Arnd Bergmann <arnd@arndb.de> Fixes: 450312b6 ("ASoC: soc-core: remove DAI suspend/resume") Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20200413124548.28197-1-krzk@kernel.orgSigned-off-by:
-
- 09 Apr, 2020 6 commits
-
-
Amadeusz Sławiński authored
Function soc_tplg_dai_config can fail, check for and handle possible failure. Signed-off-by:
-
Amadeusz Sławiński authored
Function pcm_new_ver can fail, so we should check it's return value and handle possible error. Signed-off-by:
-
Amadeusz Sławiński authored
Function soc_tplg_add_route can propagate error code from callback, we should check its return value and handle fail in correct way. Signed-off-by:
-
Amadeusz Sławiński authored
Functions soc_tplg_denum_create, soc_tplg_dmixer_create, soc_tplg_dbytes_create can fail, so their return values should be checked and error should be propagated. Signed-off-by:
-
Amadeusz Sławiński authored
Function soc_tplg_create_tlv can fail, so we should check if it succeded or not and proceed appropriately. Signed-off-by:
-
Amadeusz Sławiński authored
kstrdup is an allocation function and it can fail, so its return value should be checked and handled appropriately. In order to check all cases, we need to modify set_stream_info to return a value, so check that everything went correctly when doing kstrdup(). Later add proper checks and error handlers. Signed-off-by:
-
- 07 Apr, 2020 1 commit
-
-
Mike Willard authored
Pull the RST line low then high when initializing the driver, in order to force a reset of the chip. Previously, the line was not pulled low, which could result in the chip registers not resetting to their default values on boot. Signed-off-by:
Mike Willard <mwillard@izotope.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200401205454.79792-1-mwillard@izotope.comSigned-off-by:
-
- 06 Apr, 2020 3 commits
-
-
Hans de Goede authored
The Medion E1239T uses the default jack-detect mode 3, but instead of using an analog microphone it is using a DMIC on dmic-data-pin 1, like other models following Intel's Brasswell's reference design. This commit adds a DMI quirk pointing to the intel_braswell_platform_data for this model. Signed-off-by:
-
Hans de Goede authored
The MPMAN MPWIN895CL tablet almost fully works with out default settings. The only problem is that it has only 1 speaker so any sounds only playing on the right channel get lost. Add a quirk for this model using the default settings + MONO_SPEAKER. Signed-off-by:
-
Julia Lawall authored
The commit 0d6defc7 ("ASoC: stm32: sai: manage rebind issue") converts some function calls to their non-devm equivalents. The appropriate cleanup code was added to the remove function, but not to the probe function. Add a call to snd_dmaengine_pcm_unregister to compensate for the call to snd_dmaengine_pcm_register in case of subsequent failure. Fixes: commit 0d6defc7 ("ASoC: stm32: sai: manage rebind issue") Signed-off-by:
Julia Lawall <Julia.Lawall@inria.fr> Acked-by:
-
- 03 Apr, 2020 2 commits
-
-
Hans de Goede authored
GCC 10 gives a "variable might be used uninitialized" warning for the block variable in sst_prepare_and_post_msg(). This is a false-positive warning, but lets fix it anyways. Signed-off-by:
-
Hans de Goede authored
sst_fill_and_send_cmd_unlocked must be called with the drv->lock mutex locked already. In the past there have been cases where this was not the case, add a WARN_ON to check for drv->lock being locked. Signed-off-by:
-
