- Feb 24, 2022
-
-
Vijendar Mukunda authored
Add pre power on widget event. Based on this event update platform clock control sequence. This will fix Codec clock and pll restoration issue during system level resume. Signed-off-by:
Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20220223071959.13539-4-Vijendar.Mukunda@amd.com Signed-off-by:
Mark Brown <broonie@kernel.org>
-
Vijendar Mukunda authored
Enable no_capture_mute_flag in nau8821 codec driver. This will fix active playback stream mute issue when capture stream got closed. Signed-off-by:
-
Vijendar Mukunda authored
Refactor I2S Master mode clock programming sequence code. This will also fix the i2s clocks restore issue during system level resume. Signed-off-by:
-
- Feb 23, 2022
-
-
Srinivas Kandagatla authored
wcd934x_rx_hph_mode_put currently returns zero eventhough it changes the value. Fix this, so that change notifications are sent correctly. Fixes: 1cde8b82 ("ASoC: wcd934x: add basic controls") Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220222183212.11580-10-srinivas.kandagatla@linaro.org Signed-off-by:
-
Srinivas Kandagatla authored
set "HPH Type" Kcontrol max value of WCD_MBHC_HPH_STEREO instead of UINT_MAX. set "HPHL/R Impedance" Kcontrols max value to INT_MAX instead of UINT_MAX as max field is integer type. Without this patch amixer for these controls will show -1 as max value to userspace. Fixes: 9fb9b169 ("ASoC: codecs: wcd934x: add mbhc support") Signed-off-by:
-
Srinivas Kandagatla authored
set "HPH Type" Kcontrol max value of WCD_MBHC_HPH_STEREO instead of UINT_MAX. set "HPHL/R Impedance" Kcontrols max value to INT_MAX instead of UINT_MAX as max field is integer type. Without this patch amixer for these controls will show -1 as max value to userspace. Fixes: bcee7ed0 ("ASoC: codecs: wcd938x: add Multi Button Headset Control support") Signed-off-by:
-
Srinivas Kandagatla authored
Accessing enums using integer would result in array out of bounds access on platforms like aarch64 where sizeof(long) is 8 compared to enum size which is 4 bytes. Fix this by using enumerated items instead of integers. Fixes: e8ba1e05 ("ASoC: codecs: wcd938x: add basic controls") Signed-off-by:
-
Srinivas Kandagatla authored
Accessing enums using integer would result in array out of bounds access on platforms like aarch64 where sizeof(long) is 8 compared to enum size which is 4 bytes. Fixes: 908e6b1d ("ASoC: codecs: lpass-va-macro: Add support to VA Macro") Signed-off-by:
-
Srinivas Kandagatla authored
Accessing enums using integer would result in array out of bounds access on platforms like aarch64 where sizeof(long) is 8 compared to enum size which is 4 bytes. Fixes: 4f692926 ("ASoC: codecs: lpass-rx-macro: add dapm widgets and route") Signed-off-by:
-
Srinivas Kandagatla authored
AUX interpolator does not have compander, so check before accessing compander data for this. Without this checkan array of out bounds access will be made in comp_enabled[] array. Fixes: 4f692926 ("ASoC: codecs: lpass-rx-macro: add dapm widgets and route") Signed-off-by:
-
- Feb 17, 2022
-
-
Fabio Estevam authored
Currently, the following error messages are seen during boot: asoc-simple-card sound: control 2:0:0:SPDIF Switch:0 is already present cs4265 1-004f: ASoC: failed to add widget SPDIF dapm kcontrol SPDIF Switch: -16 Quoting Mark Brown: "The driver is just plain buggy, it defines both a regular SPIDF Switch control and a SND_SOC_DAPM_SWITCH() called SPDIF both of which will create an identically named control, it can never have loaded without error. One or both of those has to be renamed or they need to be merged into one thing." Fix the duplicated control name by combining the two SPDIF controls here and move the register bits onto the DAPM widget and have DAPM control them. Fixes: f853d6b3 ("ASoC: cs4265: Add a S/PDIF enable switch") Signed-off-by:
Fabio Estevam <festevam@denx.de> Acked-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220215120514.1760628-1-festevam@gmail.com Signed-off-by:
-
Marek Vasut authored
While the $val/$val2 values passed in from userspace are always >= 0 integers, the limits of the control can be signed integers and the $min can be non-zero and less than zero. To correctly validate $val/$val2 against platform_max, add the $min offset to val first. Fixes: 817f7c93 ("ASoC: ops: Reject out of bounds values in snd_soc_put_volsw()") Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220215130645.164025-1-marex@denx.de Signed-off-by:
-
- Feb 11, 2022
-
-
Charles Keepax authored
When parsing the compressed stream the whole buffer descriptor is now read in a single cs_dsp_coeff_read_ctrl; on older firmwares this descriptor is just 4 bytes but on more modern firmwares it is 24 bytes. The current code reads the full 24 bytes regardless, this was working but reading junk for the last 20 bytes. However commit f444da38 ("firmware: cs_dsp: Add offset to cs_dsp read/write") added a size check into cs_dsp_coeff_read_ctrl, causing the older firmwares to now return an error. Update the code to only read the amount of data appropriate for the firmware loaded. Fixes: 04ae0859 ("ASoC: wm_adsp: Switch to using wm_coeff_read_ctrl for compressed buffers") Signed-off-by:
-
- Feb 10, 2022
-
-
Stephen Boyd authored
In commit da0363f7 ("ASoC: qcom: Fix for DMA interrupt clear reg overwriting") we changed regmap_write() to regmap_update_bits() so that we can avoid overwriting bits that we didn't intend to modify. Unfortunately this change breaks the case where a register is writable but not readable, which is exactly how the HDMI irq clear register is designed (grep around LPASS_HDMITX_APP_IRQCLEAR_REG to see how it's write only). That's because regmap_update_bits() tries to read the register from the hardware and if it isn't readable it looks in the regmap cache to see what was written there last time to compare against what we want to write there. Eventually, we're unable to modify this register at all because the bits that we're trying to set are already set in the cache. This is doubly bad for the irq clear register because you have to write the bit to clear an interrupt. Given the irq is level triggered, we see an interrupt storm upon plugging in an HDMI cable and starting audio playback. The irq storm is so great that performance degrades significantly, leading to CPU soft lockups. Fix it by using regmap_write_bits() so that we really do write the bits in the clear register that we want to. This brings the number of irqs handled by lpass_dma_interrupt_handler() down from ~150k/sec to ~10/sec. Fixes: da0363f7 ("ASoC: qcom: Fix for DMA interrupt clear reg overwriting") Cc: Srinivasa Rao Mandadapu <srivasam@codeaurora.org> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20220209232520.4017634-1-swboyd@chromium.org Signed-off-by:
-
- Feb 09, 2022
-
-
Tzung-Bi Shih authored
Updates cros_ec_codec maintainers. Signed-off-by:
Tzung-Bi Shih <tzungbi@google.com> Acked-By:
Cheng-Yi Chiang <cychiang@chromium.org> Acked-By:
Benson Leung <bleung@chromium.org> Link: https://lore.kernel.org/r/20220208031242.227563-1-tzungbi@google.com Signed-off-by:
-
- Feb 08, 2022
-
-
Kai Vehmanen authored
The current rt5682_jack_detect_handler() assumes the component and card will always show up and implements an infinite usleep loop waiting for them to show up. This does not hold true if a codec interrupt (or other event) occurs when the card is unbound. The codec driver's remove or shutdown functions cannot cancel the workqueue due to the wait loop. As a result, code can either end up blocking the workqueue, or hit a kernel oops when the card is freed. Fix the issue by rescheduling the jack detect handler in case the card is not ready. In case card never shows up, the shutdown/remove/suspend calls can now cancel the detect task. Signed-off-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by:
Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by:
Shuming Fan <shumingf@realtek.com> Link: https://lore.kernel.org/r/20220207153000.3452802-3-kai.vehmanen@linux.intel.com Signed-off-by:
-
Kai Vehmanen authored
The current rt5668_jack_detect_handler() assumes the component and card will always show up and implements an infinite usleep loop waiting for them to show up. This does not hold true if a codec interrupt (or other event) occurs when the card is unbound. The codec driver's remove or shutdown functions cannot cancel the workqueue due to the wait loop. As a result, code can either end up blocking the workqueue, or hit a kernel oops when the card is freed. Fix the issue by rescheduling the jack detect handler in case the card is not ready. In case card never shows up, the shutdown/remove/suspend calls can now cancel the detect task. Signed-off-by:
-
Kai Vehmanen authored
The current rt5682s_jack_detect_handler() assumes the component and card will always show up and implements an infinite usleep loop waiting for them to show up. This does not hold true if a codec interrupt (or other event) occurs when the card is unbound. The codec driver's remove or shutdown functions cannot cancel the workqueue due to the wait loop. As a result, code can either end up blocking the workqueue, or hit a kernel oops when the card is freed. Fix the issue by rescheduling the jack detect handler in case the card is not ready. In case card never shows up, the shutdown/remove/suspend calls can now cancel the detect task. Signed-off-by:
-
Martin Povišer authored
Per TAS2770 datasheet there must be a 1 ms delay from reset to first command. So insert delays into the driver where appropriate. Fixes: 1a476abc ("tas2770: add tas2770 smart PA kernel driver") Signed-off-by:
Martin Povišer <povik+lin@cutebit.org> Link: https://lore.kernel.org/r/20220204095301.5554-1-povik+lin@cutebit.org Signed-off-by:
-
Guenter Roeck authored
This reverts commit 9de2b928 ("ASoC: mediatek: Check for error clk pointer"). With this patch in the tree, Chromebooks running the affected hardware no longer boot. Bisect points to this patch, and reverting it fixes the problem. An analysis of the code with this patch applied shows: ret = init_clks(pdev, clk); if (ret) return ERR_PTR(ret); ... for (j = 0; j < MAX_CLKS && data->clk_id[j]; j++) { struct clk *c = clk[data->clk_id[j]]; if (IS_ERR(c)) { dev_err(&pdev->dev, "%s: clk unavailable\n", data->name); return ERR_CAST(c); } scpd->clk[j] = c; } Not all clocks in the clk_names array have to be present. Only the clocks in the data->clk_id array are actually needed. The code already checks if the required clocks are available and bails out if not. The assumption that all clocks have to be present is wrong, and commit 9de2b928 ("ASoC: mediatek: Check for error clk pointer") needs to be reverted. Cc: Jiasheng Jiang <jiasheng@iscas.ac.cn> Cc: Mark Brown <broonie@kernel.org> Cc: James Liao <jamesjj.liao@mediatek.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Reported-by:
Frank Wunderlich <frank-w@public-files.de> Reported-by:
Daniel Golle <daniel@makrotopia.org> Fixes: 9de2b928 ("ASoC: mediatek: Check for error clk pointer") Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20220207160923.3911501-1-linux@roeck-us.net Signed-off-by:
-
- Feb 03, 2022
-
-
Mark Brown authored
Merge series from Mark Brown <broonie@kernel.org>: The event generation coverage I just wrote shows that the generic ASoC ops fail to generate events for stereo controls when only the first channel is changed, we just return the status for the second channel and discard that for the first.
-
V sujith kumar Reddy authored
Maxim codec driver already enabling/disabling spk_en_gpio in form of sd_mode gpio hence remove such gpio access control from machine driver to avoid conflict Signed-off-by:
V sujith kumar Reddy <vsujithkumar.reddy@amd.com> Link: https://lore.kernel.org/r/20220131203225.1418648-1-vsujithkumar.reddy@amd.com Signed-off-by:
-
Mark Brown authored
When writing out a stereo control we discard the change notification from the first channel, meaning that events are only generated based on changes to the second channel. Ensure that we report a change if either channel has changed. Signed-off-by:
-
Mark Brown authored
When writing out a stereo control we discard the change notification from the first channel, meaning that events are only generated based on changes to the second channel. Ensure that we report a change if either channel has changed. Signed-off-by:
-
Mark Brown authored
When writing out a stereo control we discard the change notification from the first channel, meaning that events are only generated based on changes to the second channel. Ensure that we report a change if either channel has changed. Signed-off-by:
-
Mark Brown authored
When writing out a stereo control we discard the change notification from the first channel, meaning that events are only generated based on changes to the second channel. Ensure that we report a change if either channel has changed. Signed-off-by:
-
- Jan 31, 2022
-
-
Christophe JAILLET authored
Since the commit in the Fixes tag below, 'wm->input_dev' is a managed resource that doesn't need to be explicitly unregistered or freed (see devm_input_allocate_device() documentation) So, remove some unless line of code to slightly simplify it. Fixes: c72f61e7 ("Input: wm97xx: split out touchscreen registering") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by:
-
- Jan 29, 2022
-
-
Mark Brown authored
The controls allow inputs to be specified as negative but our manipulating them into register fields need to be done on unsigned variables so the checks for negative numbers weren't taking effect properly. Do the checks for negative values on the variable in the ABI struct rather than on our local unsigned copy. Signed-off-by:
-
Mark Brown authored
Merge series from Takashi Iwai <tiwai@suse.de>: This is the revised patches for addressing ASoC lockdep warnings due to the recent DPCM locking refactoring.
-
- Jan 28, 2022
-
-
Peter Ujfalusi authored
On resume from suspend the following chain of events can happen: A rt5682_resume() -> mod_delayed_work() for jack_detect_work B DAPM sequence starts ( DAPM is locked now) A1. rt5682_jack_detect_handler() scheduled - Takes both jdet_mutex and calibrate_mutex - Calls in to rt5682_headset_detect() which tries to take DAPM lock, it starts to wait for it as B path took it already. B1. DAPM sequence reaches the "HP Amp", rt5682_hp_event() tries to take the jdet_mutex, but it is locked in A1, so it waits. Deadlock. To solve the deadlock, drop the jdet_mutex, use the jack_detect_work to do the jack removal handling, move the dapm lock up one level to protect the most of the rt5682_jack_detect_handler(), but not the jack reporting as it might trigger a DAPM sequence. The rt5682_headset_detect() can be changed to static as well. Fixes: 8deb34a9 ("ASoC: rt5682: fix the wrong jack type detected") Signed-off-by: -
Dmitry Osipenko authored
Correct size of iec_status array by changing it to the size of status array of the struct snd_aes_iec958. This fixes out-of-bounds slab read accesses made by memcpy() of the hdmi-codec driver. This problem is reported by KASAN. Cc: stable@vger.kernel.org Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20220112195039.1329-1-digetx@gmail.com Signed-off-by:
-
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.de Signed-off-by:
-
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.com Signed-off-by:
-
- Jan 26, 2022
-
-
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 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:
-
- Jan 25, 2022
-
-
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:
-
