- 28 Jan, 2022 3 commits
-
-
Takashi Iwai authored
The recent fix for DPCM locking also covered the loop in dpcm_be_disconnect() with the FE stream lock. This caused an unexpected side effect, thought: calling debugfs_remove_recursive() in the spinlock may lead to lockdep splats as the code there assumes the SOFTIRQ-safe context. For avoiding the problem, this patch changes the disconnection procedure to two phases: at first, the matching entries are removed from the linked list, then the resources are freed outside the lock. Fixes: b7898396 ("ASoC: soc-pcm: Fix and cleanup DPCM locking") Reported-and-tested-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20220119155249.26754-3-tiwai@suse.deSigned-off-by:
Mark Brown <broonie@kernel.org>
-
Takashi Iwai authored
The recent change for DPCM locking caused spurious lockdep warnings. Actually the warnings are false-positive, as those are triggered due to the nested stream locks for FE and BE. Since both locks belong to the same lock class, lockdep sees it as if a deadlock. For fixing this, we need to take PCM stream locks for BE with the nested lock primitives. Since currently snd_pcm_stream_lock*() helper assumes only the top-level single locking, a new helper function snd_pcm_stream_lock_irqsave_nested() is defined for a single-depth nested lock, which is now used in the BE DAI trigger that is always performed inside a FE stream lock. Fixes: b2ae8066 ("ASoC: soc-pcm: serialize BE triggers") Reported-and-tested-by:
Hans de Goede <hdegoede@redhat.com> Reported-and-tested-by:
-
Miaoqian Lin authored
Add the missing platform_device_put() and platform_device_del() before return from pcm030_fabric_probe in the error handling case. Fixes: c912fa91 ("ASoC: fsl: register the wm9712-codec") Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Link: https://lore.kernel.org/r/20220127131336.30214-1-linmq006@gmail.comSigned-off-by:
-
- 26 Jan, 2022 4 commits
-
-
Srinivas Kandagatla authored
Its possible that the sound card is just opened and closed without actually playing stream, ex: if the audio file itself is missing. Even in such cases we do call stop on graphs that are not yet started. DSP can throw errors in such cases, so add a check to see if the graph was started before stopping it. Fixes: 9b4fe0f1 ("ASoC: qdsp6: audioreach: add q6apm-dai support") Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220126113549.8853-5-srinivas.kandagatla@linaro.orgSigned-off-by:
-
Srinivas Kandagatla authored
wcd938x_ear_pa_put_gain, wcd938x_set_swr_port and wcd938x_set_compander currently returns zero eventhough it changes the value. Fix this, so that change notifications are sent correctly. Fixes: e8ba1e05 ("ASoC: codecs: wcd938x: add basic controls") Signed-off-by:
-
Srinivas Kandagatla authored
For some reason we ended up with incorrect register offfset calcuations for sidetone. regmap clearly throw errors when accessing these incorrect registers as these do not belong to any read/write ranges. so fix them to point to correct register offsets. Fixes: f3ce6f3c ("ASoC: codecs: lpass-rx-macro: add iir widgets") Signed-off-by:
-
Srinivas Kandagatla authored
Mixer controls have the channel id in mixer->reg, which is not same as port id. port id should be derived from chan_info array. So fix this. Without this, its possible that we could corrupt struct wcd938x_sdw_priv by accessing port_map array out of range with channel id instead of port id. Fixes: e8ba1e05 ("ASoC: codecs: wcd938x: add basic controls") Signed-off-by:
-
- 25 Jan, 2022 3 commits
-
-
Mark Brown authored
We don't currently validate that the values being set are within the range we advertised to userspace as being valid, do so and reject any values that are out of range. Signed-off-by:
-
Mark Brown authored
We don't currently validate that the values being set are within the range we advertised to userspace as being valid, do so and reject any values that are out of range. Signed-off-by:
-
Mark Brown authored
We don't currently validate that the values being set are within the range we advertised to userspace as being valid, do so and reject any values that are out of range. Signed-off-by:
-
- 21 Jan, 2022 1 commit
-
-
Ajit Kumar Pandey authored
We're setting wrong card codec conf for rt1019 amp devices in our machine driver. Due to this left and right amp channels data are reversed in our machines as wrong device prefix results in wrong value for "Mono LR Select" rt1019 mixer control. Reverse dev ids in codec conf with Left and Right name_prefix to fix such issue. Signed-off-by:
Ajit Kumar Pandey <AjitKumar.Pandey@amd.com> Link: https://lore.kernel.org/r/20220120133605.476138-1-AjitKumar.Pandey@amd.comSigned-off-by:
-
- 19 Jan, 2022 2 commits
-
-
Julian Braha authored
When SND_SOC_MT8195_MT6359_RT1011_RT5682 is selected, and GPIOLIB is not selected, Kbuild gives the following warning: WARNING: unmet direct dependencies detected for SND_SOC_DMIC Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && GPIOLIB [=n] Selected by [y]: - SND_SOC_MT8195_MT6359_RT1011_RT5682 [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && I2C [=y] && SND_SOC_MT8195 [=y] && MTK_PMIC_WRAP [=y] This is because SND_SOC_MT8195_MT6359_RT1011_RT5682 selects SND_SOC_DMIC without selecting or depending on GPIOLIB, depsite SND_SOC_DMIC depending on GPIOLIB. This unmet dependency bug was detected by Kismet, a static analysis tool for Kconfig. Please advise if this is not the appropriate solution. Signed-off-by:
Julian Braha <julianbraha@gmail.com> Reviewed-by:
Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20220117050324.68371-1-julianbraha@gmail.comSigned-off-by:
-
Dan Carpenter authored
Check for negative values of "priv->gain" to prevent an out of bounds access. The concern is that these might come from the user via: -> snd_ctl_elem_write_user() -> snd_ctl_elem_write() -> kctl->put() Fixes: fa8d9151 ("ASoC: max9759: Add Amplifier Driver") Signed-off-by:Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20220119123101.GA9509@kiliSigned-off-by:
-
- 12 Jan, 2022 1 commit
-
-
Jiasheng Jiang authored
If the device does not exist, of_get_child_by_name() will return NULL pointer. And devm_snd_soc_register_component() does not check it. Also, I have noticed that cpcap_codec_driver has not been used yet. Therefore, it should be better to check it in order to avoid the future dereference of the NULL pointer. Fixes: f6cdf2d3 ("ASoC: cpcap: new codec") Signed-off-by:
Jiasheng Jiang <jiasheng@iscas.ac.cn> Link: https://lore.kernel.org/r/20220111025048.524134-1-jiasheng@iscas.ac.cnSigned-off-by:
-
- 11 Jan, 2022 1 commit
-
-
Robert Hancock authored
A previous change to simple-card resulted in asoc_simple_parse_dai attempting to retrieve the dai_name for platform components, which are unlikely to have a valid DAI name. This caused simple-card to fail to probe when using the xlnx_formatter_pcm as the platform component, since it does not register any DAI components. Since the dai_name is not used for platform components, just skip trying to retrieve it for those. Fixes: f107294c ("ASoC: simple-card: support snd_soc_dai_link_component style for cpu") Signed-off-by:
Robert Hancock <robert.hancock@calian.com> Link: https://lore.kernel.org/r/20220107214711.1100162-6-robert.hancock@calian.comSigned-off-by:
-
- 10 Jan, 2022 1 commit
-
-
Robert Hancock authored
This patch is based on one in the Xilinx kernel tree, "ASoc: xlnx: Make buffer bytes multiple of period bytes" by Devarsh Thakkar. The same issue exists in the mainline version of the driver. The original patch description is as follows: "The Xilinx Audio Formatter IP has a constraint on period bytes to be multiple of 64. This leads to driver changing the period size to suitable frames such that period bytes are multiple of 64. Now since period bytes and period size are updated but not the buffer bytes, this may make the buffer bytes unaligned and not multiple of period bytes. When this happens we hear popping noise as while DMA is being done the buffer bytes are not enough to complete DMA access for last period of frame within the application buffer boundary. To avoid this, align buffer bytes too as multiple of 64, and set another constraint to always enforce number of periods as integer. Now since, there is already a rule in alsa core to enforce Buffer size = Number of Periods * Period Size this automatically aligns buffer bytes as multiple of period bytes." Fixes: 6f6c3c36 ("ASoC: xlnx: add pcm formatter platform driver") Cc: Devarsh Thakkar <devarsh.thakkar@xilinx.com> Signed-off-by:
-
- 07 Jan, 2022 2 commits
-
-
Charles Keepax authored
The cs35l41 supports a low power DSP memory retention mode. Add support for entering this mode when then device is not in use. Co-authored-by:
David Rhodes <david.rhodes@cirrus.com> Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220107160636.6555-3-ckeepax@opensource.cirrus.comSigned-off-by:
-
Charles Keepax authored
In preparation for the addition of PM runtime support move the test key out of the register patches themselves. This is necessary to allow the test key to be held during cache synchronisation, which is required by the OTP settings which were unpacked from the device and written by the driver. Also whilst at it, the driver uses a mixture of accessing the test key register by name and by address, consistently use the name. Signed-off-by:
-
- 06 Jan, 2022 14 commits
-
-
Mark Brown authored
Merge series from Shengjiu Wang <shengjiu.wang@nxp.com>: Several improvement and fixes for AK codecs supported on i.MX platfroms
-
Yassine Oudjana authored
Currently, rx_port_value is a single unsigned int that gets overwritten when slim_rx_mux_put() is called for any RX mux, then the same value is read when slim_rx_mux_get() is called for any of them. This results in slim_rx_mux_get() reporting the last value set by slim_rx_mux_put() regardless of which SLIM RX mux is in question. Turn rx_port_value into an array and store a separate value for each SLIM RX mux. Signed-off-by:
Yassine Oudjana <y.oudjana@protonmail.com> Link: https://lore.kernel.org/r/20220104033356.343685-1-y.oudjana@protonmail.comSigned-off-by:
-
Ajit Kumar Pandey authored
RT1019 components was initially registered with i2c1 and i2c2 but now changed to i2c0 and i2c1 in most of our AMD platforms. Change default rt1019 components to 10EC1019:00 and 10EC1019:01 which is aligned with most of AMD machines. Any exception to rt1019 device ids in near future board design can be handled using dmi based quirk for that machine. Signed-off-by:
-
Qinghua Jin authored
change 'postion' to 'position' Signed-off-by:
Qinghua Jin <qhjin.dev@gmail.com> Link: https://lore.kernel.org/r/20220106092847.357035-1-qhjin.dev@gmail.comSigned-off-by:
-
Shengjiu Wang authored
According to RM, the clock divider range is from 1 to 8, clock prescaling ratio may be any power of 2 from 1 to 128. So the supported divider is not all the value between 1 and 1024, just limited value in that range. Create table for the supported divder and add function to check the clock divider is available by comparing with the table. Fixes: d0250cf4 ("ASoC: fsl_asrc: Add an option to select internal ratio mode") Signed-off-by:
Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1641380883-20709-1-git-send-email-shengjiu.wang@nxp.comSigned-off-by:
-
Hans de Goede authored
Some boards have the codec IRQ hooked-up as normally, so the driver can still do things like headset vs headphones and button-press detection, but instead of using one of the JD pins of the codec, an external GPIO is used to report the jack-presence switch status of the jack. Add support for boards which have this setup and which specify which external GPIO to use in the special Android AMCR0F28 ACPI device. And add a quirk for the Asus TF103C tablet which uses this setup. Signed-off-by:
-
Hans de Goede authored
Some X86 tablets, which ship with Android as factory installed OS, specify codec IRQs/GPIOS in a special Android AMCR0F28 ACPI device. Add support for retrieving the codec IRQ from this ACPI device instead of from the 10EC5640 device describing the codec itself and enable this on Asus MemoPad 7 ME176C tablets. This fixes jack-detect not working on these tablets. Cc: Stephan Gerhold <stephan@gerhold.net> Signed-off-by:
-
Hans de Goede authored
Some boards have the codec IRQ hooked-up as normally, so the driver can still do things like headset vs headphones and button-press detection, but instead of using one of the JD pins of the codec, an external GPIO is used to report the jack-presence switch status of the jack. Add support for this. Signed-off-by:
-
Hans de Goede authored
On some boards where the firmware/fwnode information is in essence read-only (x86 + ACPI boards) the i2c_client for the codec may contain the wrong IRQ or no IRQ at all. Since we only request the IRQ once snd_soc_component_set_jack() gets called, allow machine drivers to override the IRQ with the proper one through the data parameter to snd_soc_component_set_jack(). Signed-off-by:
-
Hans de Goede authored
Change jack_work from a struct work_struct to a struct delayed_work, this is a preparation patch for adding support for boards where an external GPIO is used for jack-detect, rather then one of the JD pins of the codec. Signed-off-by:
-
Hans de Goede authored
Commit 2b9c8d2b ("ASoC: rt5640: Add the HDA header support") adds re-queuing of the jack_work on resume when rt5640->jd_src != 0. But the jack_work will unconditionally deref rt5640->jack and that might be NULL. E.g. the sound/soc/intel/boards/bytcr_rt5640.c machine driver call snd_soc_component_set_jack(codec, NULL, NULL) from pre_suspend to disable the IRQ to avoid spurious wakeups, so when rt5640_resume() runs rt5640->jack will be NULL in this case. Make the queueing of the work conditional on rt5640->jack instead of on rt5640->jd_src to fix this. Fixes: 2b9c8d2b ("ASoC: rt5640: Add the HDA header support") Cc: Oder Chiou <oder_chiou@realtek.com> Signed-off-by:
-
Shengjiu Wang authored
According to RM, on auto mode: For codec AK4458 and AK4497, the lowest ratio of MLCK/FS is 256 if sample rate is 8kHz-48kHz, For codec AK5558, the lowest ratio of MLCK/FS is 512 if sample rate is 8kHz-48kHz. With these setting the sound quality for 8kHz-48kHz can be improved. Fixes: aa736700 ("ASoC: imx-card: Add imx-card machine driver") Signed-off-by:
-
Shengjiu Wang authored
Transfer the refined slots and slot_width to akcodec_get_mclk_rate() for mclk calculation, otherwise the mclk frequency does not match with the slots and slot_width for S16_LE format, because the default slot_width is 32. Fixes: aa736700 ("ASoC: imx-card: Add imx-card machine driver") Signed-off-by:
-
Shengjiu Wang authored
The SAI on i.MX8MQ don't support one2one ratio for mclk:bclk, so the mclk frequency exceeds the supported range of codec for the case that sample rate is larger than 705kHZ and format is S32_LE. Update the supported width for such case. Fixes: aa736700 ("ASoC: imx-card: Add imx-card machine driver") Signed-off-by:
-
- 05 Jan, 2022 8 commits
-
-
Takashi Iwai authored
A randconfig caught a compile warning that is now treated as a fatal error: sound/soc/codecs/ak4375.c:415:13: error: ‘ak4375_power_off’ defined but not used [-Werror=unused-function] where ak4375_power_off() is used only from the PM handler. As both suspend and resumes are already marked with __maybe_unused, let's rip off the superfluous ifdef CONFIG_PM, so that the error above can be avoided. Fixes: 53778b82 ("ASoC: Add AK4375 support") Signed-off-by:
-
Mark Brown authored
Merge series from Charles Keepax <ckeepax@opensource.cirrus.com>: This patch series adds support for the low power hibernation feature on cs35l41. This allows the DSP memory to be retained whilst the device enters a very low power state.
-
Fabio Estevam authored
When the reset_gpio GPIO is used, it is better to put the codec back into reset state when the driver unbinds. Add a remove() function to accomplish that. Suggested-by:
Fabio Estevam <festevam@denx.de> Acked-by:
-
Charles Keepax authored
In the case a device can support retaining the firmware memory across low power states it is useful for the preloader widget to only power up whilst actually loading/unloading the core, as opposed to the normal operation where the widget is powered for the entire time a firmware is preloaded onto the core. Add support for this mode and a flag to enable it. Signed-off-by:
-
Charles Keepax authored
If the Halo registers are kept in the register cache the HALO_CORE_RESET bit will be retained as 1 after reset is triggered in cs_dsp_halo_start_core. This will cause subsequent writes to reset the core which is not desired. Apart from this bit the rest of the register bits are cacheable, so for safety sake clear the bit to ensure the cache is consistent. Signed-off-by:
-
Charles Keepax authored
It makes no sense to cache the test/user key registers, since they require values written at specific times, mark them volatile. It is probably best if they can't be accessed from user-space either, so mark them precious as well. The interrupt force, edge, polarity and debounce are all settings applied to the IRQ rather than status bits and as such should not be volatile. The OTP trim values will require re-application in the event of a cache sync and as such should not be volatile. The OTPID however should be volatile. The DSP scratch registers are used to read back an error/debug code from the DSP on shutdown, as such these should be marked volatile. Finally, add some missing defaults, add TST_FS_MON0, and allow the DSP core control register to be cached. Signed-off-by:
-
Charles Keepax authored
The wm_adsp_event should be called before the early_event on power down, event stops the core running and early_event then powers down the core. Additionally, the core should only be stopped if it was actually running in the first place. Signed-off-by:
-
Charles Keepax authored
The IRQ is not used for the PDN_DONE bit, this is polled during the DAPM sequence, remove the misleading comment. Signed-off-by:
-
