- 15 Apr, 2020 7 commits
-
-
Pierre-Louis Bossart authored
make.cross ARCH=mips allyesconfig fails with the following error: sound/soc/sof/sof-of-dev.o:(.data.sof_of_imx8qxp_desc+0x40): undefined reference to `sof_imx8x_ops'. This seems to be a Makefile order issue, solve by using the same structure as for Intel platforms. Fixes: f9ad7546 ("ASoC: SOF: imx: fix reverse CONFIG_SND_SOC_SOF_OF dependency") Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by:
Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20200409071832.2039-3-daniel.baluta@oss.nxp.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
YueHaibing authored
when do randconfig like this: CONFIG_SND_SOC_SOF_IMX8_SUPPORT=y CONFIG_SND_SOC_SOF_IMX8=y CONFIG_SND_SOC_SOF_OF=y CONFIG_IMX_DSP=m CONFIG_IMX_SCU=y there is a link error: sound/soc/sof/imx/imx8.o: In function 'imx8_send_msg': imx8.c:(.text+0x380): undefined reference to 'imx_dsp_ring_doorbell' Select IMX_DSP in SND_SOC_SOF_IMX8_SUPPORT to fix this Fixes: f9ad7546 ("ASoC: SOF: imx: fix reverse CONFIG_SND_SOC_SOF_OF dependency") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
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:
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:
-
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: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:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-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:
Olivier Moysan <olivier.moysan@st.com> Link: https://lore.kernel.org/r/1586099028-5104-1-git-send-email-Julia.Lawall@inria.frSigned-off-by:
-
- 03 Apr, 2020 4 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:
-
Hans de Goede authored
sst_send_slot_map() uses sst_fill_and_send_cmd_unlocked() because in some places it is called with the drv->lock mutex already held. So it must always be called with the mutex locked. This commit adds missing locking in the sst_set_be_modules() code-path. Fixes: 24c8d141 ("ASoC: Intel: mrfld: add DSP core controls") Signed-off-by:
-
Hans de Goede authored
Using a Canon Lake machine with the SOF driver causes dmesg to fill up with a ton of these messages: [ 275.902194] sof-audio-pci 0000:00:1f.3: firmware boot complete [ 351.529358] sof-audio-pci 0000:00:1f.3: firmware boot complete [ 560.049047] sof-audio-pci 0000:00:1f.3: firmware boot complete etc. Since the DSP is powered down when not in used this happens everytime e.g. a notification plays, polluting dmesg. Turn this messages into a debug message, matching what the code already does for the ""booting DSP firmware" message. Signed-off-by:
-
- 01 Apr, 2020 3 commits
-
-
이경택 authored
Current topology doesn't add prefix of component to new kcontrol. Signed-off-by:
Gyeongtaek Lee <gt82.lee@samsung.com> Link: https://lore.kernel.org/r/009b01d60804$ae25c2d0$0a714870$@samsung.comSigned-off-by:
-
YueHaibing authored
If I2C is n but SoundWire is m, building fails: sound/soc/codecs/rt5682.c:3716:1: warning: data definition has no type or storage class module_i2c_driver(rt5682_i2c_driver); ^~~~~~~~~~~~~~~~~ sound/soc/codecs/rt5682.c:3716:1: error: type defaults to 'int' in declaration of 'module_i2c_driver' [-Werror=implicit-int] sound/soc/codecs/rt5682.c:3716:1: warning: parameter names (without types) in function declaration Guard this use #ifdef CONFIG_I2C. Fixes: 5549ea64 ("ASoC: rt5682: fix unmet dependencies") Signed-off-by:
-
이경택 authored
soc_compr_trigger_fe() allows start or stop after pause_push. In dpcm_be_dai_trigger(), however, only pause_release is allowed command after pause_push. So, start or stop after pause in compress offload is always returned as error if the compress offload is used with dpcm. To fix the problem, SND_SOC_DPCM_STATE_PAUSED should be allowed for start or stop command. Signed-off-by:
-
