- 07 Mar, 2022 1 commit
-
-
David Rhodes authored
Fix GPIO2 polarity and direction configuration Fixes: fe1024d5 ("ASoC: cs35l41: Combine adjacent register writes") Signed-off-by:
David Rhodes <drhodes@opensource.cirrus.com> Acked-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220303173059.269657-2-tanureal@opensource.cirrus.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
- 24 Feb, 2022 9 commits
-
-
Ammar Faizi authored
Do not call snd_dma_free_pages() when snd_dma_alloc_pages() returns -ENOMEM because it leads to a NULL pointer dereference bug. The dmesg says: [ T1387] sof-audio-pci-intel-tgl 0000:00:1f.3: error: memory alloc failed: -12 [ T1387] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ T1387] #PF: supervisor read access in kernel mode [ T1387] #PF: error_code(0x0000) - not-present page [ T1387] PGD 0 P4D 0 [ T1387] Oops: 0000 [#1] PREEMPT SMP NOPTI [ T1387] CPU: 6 PID: 1387 Comm: alsa-sink-HDA A Tainted: G W 5.17.0-rc4-superb-owl-00055-g80d47f5d [ T1387] Hardware name: HP HP Laptop 14s-dq2xxx/87FD, BIOS F.15 09/15/2021 [ T1387] RIP: 0010:dma_free_noncontiguous+0x37/0x80 [ T1387] Code: [... snip ...] [ T1387] RSP: 0000:ffffc90002b87770 EFLAGS: 00010246 [ T1387] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ T1387] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888101db30d0 [ T1387] RBP: 00000000fffffff4 R08: 0000000000000000 R09: 0000000000000000 [ T1387] R10: 0000000000000000 R11: ffffc90002b874d0 R12: 0000000000000001 [ T1387] R13: 0000000000058000 R14: ffff888105260c68 R15: ffff888105260828 [ T1387] FS: 00007f42e2ffd640(0000) GS:ffff888466b80000(0000) knlGS:0000000000000000 [ T1387] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ T1387] CR2: 0000000000000000 CR3: 000000014acf0003 CR4: 0000000000770ee0 [ T1387] PKRU: 55555554 [ T1387] Call Trace: [ T1387] <TASK> [ T1387] cl_stream_prepare+0x10a/0x120 [snd_sof_intel_hda_common 146addf995b9279ae7f509621078cccbe4f875e1] [... snip ...] [ T1387] </TASK> Cc: Daniel Baluta <daniel.baluta@nxp.com> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Keyon Jie <yang.jie@linux.intel.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Rander Wang <rander.wang@intel.com> Cc: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.com> Cc: sound-open-firmware@alsa-project.org Cc: alsa-devel@alsa-project.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # v5.2+ Fixes: d16046ff ("ASoC: SOF: Intel: Add Intel specific HDA firmware loader") Link: https://lore.kernel.org/lkml/20220224145124.15985-1-ammarfaizi2@gnuweeb.org/ # v1 Link: https://lore.kernel.org/lkml/20220224180850.34592-1-ammarfaizi2@gnuweeb.org/ # v2 Link: https://lore.kernel.org/lkml/20220224182818.40301-1-ammarfaizi2@gnuweeb.org/ # v3 Reviewed-by:
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by:
Ammar Faizi <ammarfaizi2@gnuweeb.org> Link: https://lore.kernel.org/r/20220224185836.44907-1-ammarfaizi2@gnuweeb.orgSigned-off-by:
-
Ricard Wanderlof authored
snd_soc_component_update_bits returns 1 if the operation was successful and some bits were changed, so we cannot return this value directly as it can be interpreted as an error. Instead, do some minor mangling to avoid inadvertently returning an error. Signed-off-by:
Ricard Wanderlof <ricardw@axis.com> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2202241021420.20760@lnxricardw1.se.axis.comSigned-off-by:
-
Derek Fang authored
Some powers were changed during the jack insert detection and clk's enable/disable in CCF. If in parallel, the influence has a chance to detect the wrong jack type. We refer to the below commit of the variant codec (rt5682) to fix this issue. ASoC: rt5682: Fix deadlock on resume 1. Remove rt5682s_headset_detect in rt5682s_jd_check_handler and use jack_detect_work instead of. 2. Use dapm mutex used in CCF to protect most of jack_detect_work. Signed-off-by:
Derek Fang <derek.fang@realtek.com> Link: https://lore.kernel.org/r/20220223101450.4577-1-derek.fang@realtek.comSigned-off-by:
-
Hans de Goede authored
The Lenovo Yoga Tablet 2 1050F/L tablets use an ACPI HID of "10WM5102" for their wm5102 codec, add this to the list of HIDs for the wm5102 codec. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20220223135237.731638-1-hdegoede@redhat.comSigned-off-by:
-
Vijendar Mukunda authored
As part of ACP programming sequence, ACP_CONTROL and ACP_CLKMUX_SEL registers should be updated during acp init and de-init sequence. This patch updates register sequence during ACP init and deinit. Signed-off-by:
Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20220223071959.13539-6-Vijendar.Mukunda@amd.comSigned-off-by:
-
Vijendar Mukunda authored
ACP I2S controller has limitation to program different BCLK for TX and RX paths. Headset path uses I2S SP controller instance. As per requirement, Restricted 32 bits as sample bits by applying pcm constraint in startup calabck for Headset path. Signed-off-by:
-
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 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:
-
- 23 Feb, 2022 7 commits
-
-
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.orgSigned-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:
-
- 16 Feb, 2022 2 commits
-
-
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:
-
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.deSigned-off-by:
-
- 10 Feb, 2022 2 commits
-
-
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:
-
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.orgSigned-off-by:
-
- 09 Feb, 2022 1 commit
-
-
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.comSigned-off-by:
-
- 08 Feb, 2022 5 commits
-
-
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:
Shuming Fan <shumingf@realtek.com> Link: https://lore.kernel.org/r/20220207153000.3452802-3-kai.vehmanen@linux.intel.comSigned-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.orgSigned-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.netSigned-off-by:
-
- 02 Feb, 2022 6 commits
-
-
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.comSigned-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:
-
- 31 Jan, 2022 1 commit
-
-
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:
-
- 28 Jan, 2022 6 commits
-
-
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.
-
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.comSigned-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.deSigned-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:
-
