- 21 Feb, 2022 7 commits
-
-
Mohan Kumar authored
Tegra234 chip scratch register communication between audio and hdmi driver differs slightly in the way it triggers the interrupt compared to legacy chips. Interrupt is triggered by writing non-zero values to verb 0xF80 instead of 31st bit of scratch register. DP MST support changed the NID to be used for scratch register read/write from audio function group NID to Converter widget NID. Signed-off-by:
Mohan Kumar <mkumard@nvidia.com> Link: https://lore.kernel.org/r/20220216092240.26464-4-mkumard@nvidia.comSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
Mohan Kumar authored
The GCAP register on Tegra234 implies no Input Streams(ISS) supported, but the HW output stream descriptor programming should start with offset 0x20*4 from base stream descriptor address. This will be a problem while calculating the offset for output stream descriptor which will be considering input stream also. So here output stream starts with offset 0 which is wrong as HW register for output stream offset starts with 4. So hardcode the input stream numbers to 4 to avoid the issue in offset calculation. Signed-off-by:
-
Mohan Kumar authored
Add hda driver support for the Tegra234 chip. The hdacodec on this chip now supports DP MST feature, HDA block contains azalia controller and one hda-codec instance by supporting 4 independent output streams over DP MST mode. There is no input stream support. Signed-off-by:
-
Cezary Rojewski authored
With few changes, snd_hda_codec_set_power_save() and snd_hda_codec_cleanup_for_unbind() can be re-used by ASoC drivers. While at it, provide kernel doc for the exposed functions. Signed-off-by:
Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20220214101404.4074026-5-cezary.rojewski@intel.comSigned-off-by:
-
Cezary Rojewski authored
With few changes, snd_hda_codec_register() and its unregister-counterpart can be re-used by ASoC drivers. While at it, provide kernel doc for the exposed functions. Due to ALSA-device vs ASoC-component organization differences, new 'snddev_managed' argument is specified allowing for better control over codec registration process. Signed-off-by:
-
Cezary Rojewski authored
With few changes, snd_hda_codec_device_init() can be re-used by ASoC drivers. While at it, provide kernel doc for the exposed function. Signed-off-by:
-
Cezary Rojewski authored
This patch exposes a new helper to directly retrieve the link from the codec address, and makes use of this helper when retrieving the link from the codec name. Signed-off-by:
-
- 17 Feb, 2022 1 commit
-
-
Kai Vehmanen authored
Implement HDA keep alive (KAE) support for Intel display codecs. When no audio stream is active, the display codec will provide a continuous clock and a valid but silent audio stream to any connected HDMI/DP receiver. Without this, upon starting a new playback stream, initial samples may be lost as many receivers require time to initialize for new clock. This is a new feature in Intel AlderLake-P display codec implementation and replaces the Intel i915 silent-stream extension that has been used on older hardware. Main benefit of the new method is that codec no longer needs to be kept in D0 power state. This patch depends on commit 112a87c4 ("drm/i915/display: program audio CDCLK-TS for keepalives"). [ a minor coding-style fix by tiwai ] Signed-off-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by:
Jyri Sarha <jyri.sarha@intel.com> Link: https://lore.kernel.org/r/20220216172405.3994959-1-kai.vehmanen@linux.intel.comSigned-off-by:
-
- 15 Feb, 2022 2 commits
-
-
Takashi Iwai authored
-
Takashi Iwai authored
Merge tag 'platform-drivers-x86-serial-multi-instantiate-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 into for-next This branch contains 5.17-rc1 + the SPI tree's spi-acpi-helpers tag + the other patches from the "[PATCH v6 0/9] Support Spi in i2c-multi-instantiate driver" series.
-
- 14 Feb, 2022 7 commits
-
-
Takashi Iwai authored
Merge tag 'asoc-fix-v5.17-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.18 More fixes that have arrived in the past few -rcs, plus a MAINTAINERS update. The biggest update here is the fix for control change notifications in ASoC generic controls found by mixer-test.
-
Takashi Iwai authored
The recently introduced coef_mutex for Realtek codec seems causing a deadlock when the relevant code is invoked from the power-off state; then the HD-audio core tries to power-up internally, and this kicks off the codec runtime PM code that tries to take the same coef_mutex. In order to avoid the deadlock, do the temporary power up/down around the coef_mutex acquisition and release. This assures that the power-up sequence runs before the mutex, hence no re-entrance will happen. Fixes: b837a9f5 ("ALSA: hda: realtek: Fix race at concurrent COEF updates") Reported-and-tested-by:
Julian Wollrath <jwollrath@web.de> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220214132838.4db10fca@schienar Link: https://lore.kernel.org/r/20220214130410.21230-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The default mixer resume code treats the errors at restoring the modified mixer items as a fatal error, and it returns back to the caller. This ends up in the resume failure, and the device will be come unavailable, although basically those errors are intermittent and can be safely ignored. The problem itself has been present from the beginning, but it didn't hit usually because the code tries to resume only the modified items. But now with the recent commit to forcibly initialize each item at the probe time, the problem surfaced more often, hence it appears as a regression. This patch fixes the regression simply by ignoring the errors at resume. Fixes: b96681bd ("ALSA: usb-audio: Initialize every feature unit once at probe time") Cc: <stable@vger.kernel.org> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215561 Link: https://lore.kernel.org/r/20220214125711.20531-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
By some unknown reason, BIOS on Shenker Dock 15 doesn't set up the codec mask properly for the onboard audio. Let's set the forced codec mask to enable the codec discovery. Reported-by: dmummenschanz@web.de Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/trinity-f018660b-95c9-442b-a2a8-c92a56eb07ed-1644345967148@3c-app-webde-bap22 Link: https://lore.kernel.org/r/20220214100020.8870-2-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The forced probe mask via probe_mask 0x100 bit doesn't work any longer as expected since the bus init code was moved and it's clearing the codec_mask value that was set beforehand. This patch fixes the long-time regression by moving the check_probe_mask() call. Fixes: a41d1224 ("ALSA: hda - Embed bus into controller object") Reported-by: dmummenschanz@web.de Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/trinity-f018660b-95c9-442b-a2a8-c92a56eb07ed-1644345967148@3c-app-webde-bap22 Link: https://lore.kernel.org/r/20220214100020.8870-1-tiwai@suse.deSigned-off-by:
-
Yu Huang authored
Legion Y9000X 2019 has the same speaker with Y9000X 2020, but with a different quirk address. Add one quirk entry to make the speaker work on Y9000X 2019 too. Signed-off-by:
Yu Huang <diwang90@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220212160835.165065-1-diwang90@gmail.comSigned-off-by:
-
Matteo Martelli authored
Commit 83b7dcbc introduced a generic implicit feedback parser, which fails to execute for M-Audio FastTrack Ultra sound cards. The issue is with the ENDPOINT_SYNCTYPE check in add_generic_implicit_fb() where the SYNCTYPE is ADAPTIVE instead of ASYNC. The reason is that the sync type of the FastTrack output endpoints are set to adaptive in the quirks table since commit 65f04443. Fixes: 83b7dcbc ("ALSA: usb-audio: Add generic implicit fb parsing") Signed-off-by:
Matteo Martelli <matteomartelli3@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220211224913.20683-2-matteomartelli3@gmail.comSigned-off-by:
-
- 11 Feb, 2022 2 commits
-
-
Tom Rix authored
Remove the second 'device'. Signed-off-by:
Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20220209150133.2291856-1-trix@redhat.comSigned-off-by:
-
Kai Vehmanen authored
Add a set of HD Audio PCI IDs, and the HDMI codec VID, for Intel Raptor Lake. Signed-off-by:
-
- 10 Feb, 2022 5 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:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220210172053.22782-1-ckeepax@opensource.cirrus.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
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:
-
Takashi Iwai authored
ca0106 driver code uses too generic names for its register definitions such as PTR, DATA, IPR, etc, which may eventually conflict with other code. This patch renames (some of) those register definitions with CA0106_ prefix to avoid the conflicts. Link: https://lore.kernel.org/r/20220210124227.11272-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
It seems that calling invalidate_kernel_vmap_range() is more correct to be called before dma_sync_*(), judging from the other thread: https://lore.kernel.org/all/20220111085958.GA22795@lst.de/ Although this won't matter much in practice, let's fix the call order for consistency. Fixes: a25684a9 ("ALSA: memalloc: Support for non-contiguous page allocation") Reported-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220210123344.8756-3-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
dma_need_sync() checks each DMA address. Fix the incorrect usages for non-contiguous and non-coherent page allocations. Fortunately, there are no actual call sites that need manual syncs yet. Fixes: a25684a9 ("ALSA: memalloc: Support for non-contiguous page allocation") Fixes: 73325f60 ("ALSA: memalloc: Support for non-coherent page allocation") Cc: <stable@vger.kernel.org> Reported-by:
-
- 09 Feb, 2022 2 commits
-
-
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:
-
Takashi Iwai authored
HD-audio driver handles the multiple instances and keeps the static index that is incremented at each probe. This becomes a problem when user tries to re-bind the device via sysfs multiple times; as the device index isn't cleared unlike rmmod case, it points to the next element at re-binding, and eventually later you can't probe any more when it reaches to SNDRV_CARDS_MAX (usually 32). This patch is an attempt to improve the handling at rebinding. Instead of a static device index, now we keep a bitmap and assigns to the first zero bit position. At the driver remove, in return, the bitmap slot is cleared again, so that it'll be available for the next probe. Reported-by:
Alexander Sergeyev <sergeev917@gmail.com> Link: https://lore.kernel.org/r/20220209081912.20687-1-tiwai@suse.deSigned-off-by:
-
- 08 Feb, 2022 7 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:
Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by:
Ranjani Sridharan <ranjani.sridharan@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.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:
-
Colin Ian King authored
There are some spelling mistakes in some ksft messages. Fix them. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Reviewed-by:
Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20220207092235.240284-1-colin.i.king@gmail.comSigned-off-by:
-
Colin Ian King authored
The variable c is being initialized in an outer for-loop and also re-initialized inside an inner for-loop. The first initialization is redundant and can be removed. Signed-off-by:
-
- 04 Feb, 2022 2 commits
-
-
Mark Brown authored
This program has only one file so most functions can be static. Signed-off-by:
Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20220202150902.19563-2-broonie@kernel.orgSigned-off-by:
-
Mark Brown authored
Add some coverage of event generation to mixer-test. Rather than doing a separate set of writes designed to trigger events we add a step to the existing write_and_verify() which checks to see if the value we read back from non-volatile controls matches the value before writing and that an event is or isn't generated as appropriate. The "tests" for events then simply check that no spurious or missing events were detected. This avoids needing further logic to generate appropriate values for each control type and maximises coverage. When checking for events we use a timeout of 0. This relies on the kernel generating any event prior to returning to userspace when setting a control. That is currently the case and it is difficult to see it changing, if it does the test will need to be updated. Using a delay of 0 means that we don't slow things down unduly when checking for no event or when events fail to be generated. We don't check behaviour for volatile controls since we can't tell what the behaviour is supposed to be for any given control. Signed-off-by:
-
- 02 Feb, 2022 5 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.
-
Lucas Tanure authored
The ACPI device with CSC3551 or CLSA0100 are sound cards with multiple instances of CS35L41 connected by I2C or SPI to the main CPU. We add an ID to the ignore_serial_bus_ids list to enumerate all I2C or SPI devices correctly. The same IDs are also added into serial-multi-instantiate so that the driver can correctly enumerate the ACPI. Signed-off-by:
Lucas Tanure <tanureal@opensource.cirrus.com> Signed-off-by:
Stefan Binding <sbinding@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220121172431.6876-10-sbinding@opensource.cirrus.comReviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Lucas Tanure authored
Add support for two and four CS35L41 using the component binding method Signed-off-by:
-
Stefan Binding authored
Add support for spi bus in serial-multi-instantiate driver Some peripherals can have either a I2C or a SPI connection to the host (but not both) but use the same HID for both types. So it is not possible to use the HID to determine whether it is I2C or SPI. The driver must check the node to see if it contains I2cSerialBus or SpiSerialBus entries. For backwards-compatibility with the existing nodes I2C is checked first and if such entries are found ONLY I2C devices are created. Since some existing nodes that were already handled by this driver could also contain unrelated SpiSerialBus nodes that were previously ignored, and this preserves that behavior. If there is ever a need to handle a node where both I2C and SPI devices must be instantiated this can be added in future. Signed-off-by:
-
Lucas Tanure authored
Reorganize I2C functions to accommodate SPI support Split the probe and factor out parts of the code that will be used in the SPI support Also switched from strlcpy() to strscpy() Signed-off-by:
-
