- 08 May, 2024 1 commit
-
-
Stefan Binding authored
IRQs used for CS35L41 HDA are used to detect and attempt to recover from errors. Without these interrupts, the driver should behave as normal. For laptops which contain a bad configuration for the interrupt in the BIOS, the current behaviour of failing when trying to configure the interrupt means the probe fails, and audio is broken. It is better for the user experience if the driver instead warns that no interrupt is configured rather than simply failing. The drawback is that if an error occurs without the interrupt, we firstly would not be able to trace the issue, and secondly would not be able to attempt to recover from the issue, but this is better than failing immediately. Signed-off-by:
Stefan Binding <sbinding@opensource.cirrus.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20240429154853.9393-2-sbinding@opensource.cirrus.com
-
- 28 Apr, 2024 12 commits
-
-
Takashi Iwai authored
Pull emu10k1 fixes from Oswald Buddenhagen Signed-off-by: -
Oswald Buddenhagen authored
... into snd_emu1010_load_firmware_entry(). This makes it clearer that these steps belong together tightly, as implied by prior commits. Signed-off-by:
Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Signed-off-by:
-
Oswald Buddenhagen authored
It is a low-level I/O access function, so io.c is the natural place for it. While we're moving the code, reduce the scope of some variables, use compound assignment operators, and add/adjust some comments. Signed-off-by:
-
Oswald Buddenhagen authored
There is only one call site, and there we already know that we actually have a firmware. Signed-off-by:
-
Oswald Buddenhagen authored
Firstly, it is pointless to explicitly disable the power to the dock prior to resetting the FPGA, as the latter will do the former anyway. Secondly, it doesn't make much sense to check whether the FPGA is already programmed. It's much simpler to just presume it is, and issue the self-reset command. If it isn't, the effect isn't worse than the checks themselves. As a side effect, we lose the info if the reset fails, but there is no plausible way how that could happen unless the card burns out while operating, and in that case we'll detect a firmware upload failure a bit later anyway. Signed-off-by:
-
Oswald Buddenhagen authored
We did not delay after the second strobe signal, so another immediately following access could potentially corrupt the written value. This is a purely speculative fix with no supporting evidence, but after taking out the spinlocks around the writes, it seems plausible that a modern processor could be actually too fast. Also, it's just cleaner to be consistent. Signed-off-by:
-
Oswald Buddenhagen authored
A side effect of making the dock monitoring interrupt-driven was that we'd be very quick to program a freshly connected dock. However, for unclear reasons, the dock does not work when we do that - despite the FPGA netlist upload going just fine. We work around this by adding a delay before programming the dock; for safety, the value is several times as much as was determined empirically. Note that a badly timed dock hot-plug would have triggered the problem even before the referenced commit - but now it would happen 100% instead of about 3% of the time, thus making it impossible to work around by re-plugging. Fixes: fbb64eed ("ALSA: emu10k1: make E-MU dock monitoring interrupt-driven") Link: https://bugzilla.kernel.org/show_bug.cgi?id=218584Signed-off-by:
-
Oswald Buddenhagen authored
The FPGA access through the GPIO port does not interfere with other sound processor register access, so there is no need to subject it to emu_lock. And after moving all FPGA access out of the interrupt handler, it does not need to be IRQ-safe, either. What's more, attaching the dock causes a firmware upload, which takes several seconds. We really don't want to disable IRQs for this long, and even less also have someone else spin with IRQs disabled waiting for us. Therefore, use a mutex for FPGA access locking. This makes the code somewhat more noisy, as we need to wrap bigger sections into the mutex, as it needs to enclose the spinlocks. The latter has the "side effect" of fixing dock FPGA programming in a corner case: a really badly timed mixer access right between entering FPGA programming mode and uploading the netlist would mess up the protocol. Signed-off-by:
-
Oswald Buddenhagen authored
The actual event processing was already done by workqueue items. We can move the event dispatching there as well, rather than doing it already in the interrupt handler callback. This change has a rather profound "side effect" on the reliability of the FPGA programming: once we enter programming mode, we must not issue any snd_emu1010_fpga_{read,write}() calls until we're done, as these would badly mess up the programming protocol. But exactly that would happen when trying to program the dock, as that triggers GPIO interrupts as a side effect. This is mitigated by deferring the actual interrupt handling, as workqueue items are not re-entrant. To avoid scheduling the dispatcher on non-events, we now explicitly ignore GPIO IRQs triggered by "uninteresting" pins, which happens a lot as a side effect of calling snd_emu1010_fpga_{read,write}(). Fixes: fbb64eed ("ALSA: emu10k1: make E-MU dock monitoring interrupt-driven") Link: https://bugzilla.kernel.org/show_bug.cgi?id=218584Signed-off-by: -
Oswald Buddenhagen authored
Pulled out of the next patch to improve its legibility. As the function is now available, call it directly from snd_emu10k1_emu1010_init(), thus making the MicroDock firmware loading synchronous - there isn't really a reason not to. Note that this does not affect the AudioDocks of rev1 cards, as these have no independent power supplies, and thus come up only a while after the main card is initialized. As a drive-by, adjust the priorities of two messages to better reflect their impact. Signed-off-by:
-
Oswald Buddenhagen authored
While there are two separate IRQ status bits for dock attach and detach, the hardware appears to mix them up more or less randomly, making them useless for tracking what actually happened. It is much safer to check the dock status separately and proceed based on that, as the old polling code did. Note that the code assumes that only the dock can be hot-plugged - if other option card bits changed, the logic would break. Fixes: fbb64eed ("ALSA: emu10k1: make E-MU dock monitoring interrupt-driven") Link: https://bugzilla.kernel.org/show_bug.cgi?id=218584Signed-off-by:
-
Takashi Sakamoto authored
Some data for testing is immutable. In the case, the const qualifier is available for any loader to place it to read-only segment. Fixes: 3e39acf5 ("ALSA: core: Add sound core KUnit test") Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Acked-by:
Ivan Orlov <ivan.orlov0322@gmail.com> Signed-off-by:
-
- 26 Apr, 2024 1 commit
-
-
Colin Ian King authored
Don't populate the read-only array buf_samples on the stack at run time, instead make it static const. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Acked-by:
-
- 24 Apr, 2024 3 commits
-
-
Andy Shevchenko authored
Instead of reiterating the list, use list_for_each_entry_safe() that allows to continue without starting over. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Jaroslav Kysela <perex@perex.cz> Message-ID: <20240424145020.1057216-1-andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Stefan Binding authored
Add laptop using CS35L41 HDA. This laptop does not have _DSD, so require entries in property configuration table for cs35l41_hda driver. Signed-off-by:
-
Stefan Binding authored
This laptop does not have the correct _DSD settings, so needs to obtain its configuration from the configuration table. Signed-off-by:
-
- 21 Apr, 2024 1 commit
-
-
Nathan Chancellor authored
Clang warns (or errors with CONFIG_WERROR): sound/usb/mixer_scarlett2.c:3697:6: error: variable 'err' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] 3697 | if (private->autogain_updated) { | ^~~~~~~~~~~~~~~~~~~~~~~~~ sound/usb/mixer_scarlett2.c:3707:9: note: uninitialized use occurs here 3707 | return err; | ^~~ sound/usb/mixer_scarlett2.c:3697:2: note: remove the 'if' if its condition is always true 3697 | if (private->autogain_updated) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sound/usb/mixer_scarlett2.c:3688:9: note: initialize the variable 'err' to silence this warning 3688 | int err; | ^ | = 0 1 error generated. Initialize ret to zero to ensure ret is initialized in all paths within scarlett2_ag_target_ctl_get(), which matches the style of other functions in this driver. Fixes: e30ea534 ("ALSA: scarlett2: Add autogain target controls") Signed-off-by:Nathan Chancellor <nathan@kernel.org> Message-ID: <20240419-alsa-scarlett2-fix-wsometimes-uninitialized-v1-1-e2ace8642e08@kernel.org> Signed-off-by:
-
- 19 Apr, 2024 3 commits
-
-
Takashi Iwai authored
Although the purpose of dummy seq client is a direct pass-through, it's sometimes helpful for debugging if it can convert to a certain UMP MIDI version. This patch adds an option to specify the UMP event conversion. As default, it skips the conversion and does passthrough, while user can pass ump=1 or ump=2 to enforce the conversion to UMP MIDI1 or MIDI2 format. Message-ID: <20240419101105.15571-1-tiwai@suse.de> Signed-off-by: -
Takashi Iwai authored
The conversion from MIDI2 to MIDI1 UMP messages had a leftover artifact (superfluous bit shift), and this resulted in the bogus type check, leading to empty outputs. Let's fix it. Fixes: e9e02819 ("ALSA: seq: Automatic conversion of UMP events") Cc: <stable@vger.kernel.org> Link: https://github.com/alsa-project/alsa-utils/issues/262 Message-ID: <20240419100442.14806-1-tiwai@suse.de> Signed-off-by:
-
Ai Chao authored
The Haier Boyue G42 with ALC269VC cannot detect the MIC of headset, the line out and internal speaker until ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS quirk applied. Signed-off-by:
Ai Chao <aichao@kylinos.cn> Cc: <stable@vger.kernel.org> Message-ID: <20240419082159.476879-1-aichao@kylinos.cn> Signed-off-by:
-
- 18 Apr, 2024 19 commits
-
-
Mauro Carvalho Chehab authored
The headset mic requires a fixup to be properly detected/used. As a reference, this specific model from 2021 reports the following devices: https://alsa-project.org/db/?f=1a5ddeb0b151db8fe051407f5bb1c075b7dd3e4aSigned-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org> Cc: <stable@vger.kernel.org> Message-ID: <b92a9e49fb504eec8416bcc6882a52de89450102.1713370457.git.mchehab@kernel.org> Signed-off-by:
-
Pavel Hofman authored
Many modern codecs support rates up to 768kHz (including DSD1024). Add support for rates up to 768kHz to the loopback driver. Signed-off-by:
Pavel Hofman <pavel.hofman@ivitera.com> Reviewed-by:
-
Pavel Hofman authored
Many modern codecs support 705.6kHz and 768kHz sample rates. Current HW params fail to set 705.6kHz and 768kHz sample rates as these are not in the known-rates list. Add these new rates to the known-rates list to allow them. Also add defines in pcm.h so that drivers can use it. Signed-off-by:
-
Pavel Hofman authored
The snd-aloop loopback driver does not modify or access the actual samples in any way, defines no volume or mute controls, it's strictly bitperfect. Therefore DSD formats can be supported without any modification. Add all DSD formats to the list of supported formats. Signed-off-by:
-
Huayu Zhang authored
change HDA & AMP configuration from ALC287_FIXUP_CS35L41_I2C_2 to ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD for ThinkBook 16P Gen4 models to fix volumn control issue (cannot fully mute). Signed-off-by:
Huayu Zhang <zhanghuayu1233@qq.com> Fixes: 6214e24c ("ALSA: hda/realtek: Add quirks for Lenovo Thinkbook 16P laptops") Message-ID: <tencent_37EB880C5E5BD99D21C16B288115C4545F06@qq.com> Signed-off-by:
-
Vitalii Torshyn authored
Added the correct pin table for Asus GU605M and GA403U, enabling all speakers to be controlled with the master. Updated quirks for GU605M and GA403U by including the pin table patch in the chain. Co-developed-by:
Luke D. Jones <luke@ljones.dev> Signed-off-by:
Vitalii Torshyn <vitaly.torshyn@gmail.com> Message-ID: <20240411125803.18539-1-vitaly.torshyn@gmail.com> Signed-off-by:
-
Stefan Binding authored
These laptops do not have _DSD and must be added by configuration table, however, the initial entries for them are incorrect: Neither laptop contains a Speaker ID GPIO. This issue would not affect audio playback, but may affect which files are loaded when loading firmware. Fixes: b67a7dc4 ("ALSA: hda/realtek: Add sound quirks for Lenovo Legion slim 7 16ARHA7 models") Signed-off-by:
-
Richard Fitzgerald authored
In every case the 'dir' argument to cs35l41_request_firmware_file() is passed the string "cirrus/", so this is a redundant argument and can be removed. Signed-off-by:
Richard Fitzgerald <rf@opensource.cirrus.com> Signed-off-by:
-
Stefan Binding authored
The original mechanism for applying calibration assumed that the calibration data would be ordered the same as the amp instances. However, for some 4 amp laptops, this is not the case. To ensure that the correct calibration is applied to the correct amp, the calibration data contains a unique id, which matches a unique id inside the CS35L41. This can be used to match to the correct data entry. This mechanism is available inside the shared module cs-amp-lib. Signed-off-by:
-
Stefan Binding authored
Currently, all PC systems are set to use VBSTMON for DSP1RX5_SRC, however, this is required only for external boost systems. Internal boost systems require VPMON instead of VBSTMON to be the input to DSP1RX5_SRC. All systems require DSP1RX6_SRC to be set to VBSTMON. Also fix incorrect comment for DACPCM1_SRC to use DSP1TX1. Signed-off-by:
-
Stefan Binding authored
Add 4 laptops using CS35L41 HDA. None of these laptops have _DSD, so require entries in property configuration table for cs35l41_hda driver. Signed-off-by:
-
Stefan Binding authored
Add support for 2 new HP Omen models without _DSD into configuration table. These laptops use the PCM Gain setting for the tuning setting file. Signed-off-by:
-
Stefan Binding authored
Some systems requires different max PCM Gains settings than the default. The current default value, when running firmware is 17.5 dB, which is used for all systems. Some systems require lower values. Value when running without firmware is 4.5 dB and remains unchanged. Since the gain value is dependent on Tuning and Firmware, it can change, so it cannot be saved in _DSD. Instead we can store it inside a configuration binary file alongside the Firmware and Tuning files. The gain value increments in steps of 1 dB, with value 0 representing 0.5 dB. The max value is 20, which corresponds to 20.5 dB. Signed-off-by:
-
Shenghao Ding authored
Add new vendor_id and subsystem_id to support new Lenovo laptop ThinkPad ICE-1 Signed-off-by:
Shenghao Ding <shenghao-ding@ti.com> Cc: <stable@vger.kernel.org> Message-ID: <20240411091823.1644-1-shenghao-ding@ti.com> Signed-off-by:
-
Peter Ujfalusi authored
It is recommended that on Lunar Lake the PIO (immediate command response) is used instead of CORB/RIRB for commands/verbs. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by:
Liam Girdwood <liam.r.girdwood@intel.com> Acked-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Peter Ujfalusi authored
It is recommended that on Lunar Lake the PIO (immediate command response) is used instead of CORB/RIRB for commands/verbs. Signed-off-by:
-
Peter Ujfalusi authored
Set the use_pio_for_commands flag in case AZX_DCAPS_PIO_COMMANDS quirk is enabled. When the PIO command mode is used we can re-use the existing azx_single_send_cmd() / azx_single_get_response() functions safely as the CORB DMA is not going to be enabled in snd_hdac_bus_init_cmd_io(). Signed-off-by:
-
Peter Ujfalusi authored
In case the use_pio_for_commands flag is set we must not enable the CORB DMA to make sure that it is not interfering with the immediate command mode. Convert the snd_hdac_bus_send_cmd/snd_hdac_bus_get_response as wrappers to call either the PIO or CORB based command handling depending on the use_pio_for_commands flag. Signed-off-by:
-
Peter Ujfalusi authored
Add AZX_DCAPS_PIO_COMMANDS quirk (bit 31) and use_pio_for_commands flag to be able to select PIO mode as alternative for CORB based command sending while retaining the RIRB functionality to receive unsolicited responses. This mode differs from the azx single_cmd mode when RIRB is disabled. The mixed mode is needed on Lunar Lake family because it is recommended to use Immediate Command Response (PIO mode) instead of CORB for HDA commands. Signed-off-by:
-
