- 08 May, 2024 6 commits
-
-
Andy Shevchenko authored
The correct suffix is 'y' for the kernel code and 'objs' for the user space. Update documentation. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240506085219.3403731-1-andriy.shevchenko@linux.intel.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Chaitanya Kumar Borah authored
Add HD Audio PCI ID and HDMI codec vendor ID for Intel Battlemage. Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Link: https://lore.kernel.org/r/20240506052531.1150062-1-chaitanya.kumar.borah@intel.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Wolfram Sang authored
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_for_completion_timeout() causing patterns like: timeout = wait_for_completion_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Fix to the proper variable type 'unsigned long' while here. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20240430121028.30443-1-wsa+renesas@sang-engineering.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Manuel Barrio Linares authored
This adds support for all sample rates supported by the hardware,Digidesign Mbox 3 supports: {44100, 48000, 88200, 96000} Fixes syncing clock issues that presented as pops. To test this, without this patch playing 440hz tone produces pops. Clock is now synced between playback and capture interfaces so no more latency drift issue when using pipewire pro-profile. (https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3900) Signed-off-by: Manuel Barrio Linares <mbarriolinares@gmail.com> Link: https://lore.kernel.org/r/20240430171020.192285-1-mbarriolinares@gmail.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Stefan Binding authored
All of these laptops do not have _DSD, so need to be added to the configuration table. 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-3-sbinding@opensource.cirrus.com
-
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: Takashi Iwai <tiwai@suse.de>
-
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: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093717.3198716-5-oswald.buddenhagen@gmx.de>
-
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 <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093717.3198716-4-oswald.buddenhagen@gmx.de>
-
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 <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093717.3198716-3-oswald.buddenhagen@gmx.de>
-
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 <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093717.3198716-2-oswald.buddenhagen@gmx.de>
-
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 <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093716.3198666-7-oswald.buddenhagen@gmx.de>
-
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 <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093716.3198666-6-oswald.buddenhagen@gmx.de>
-
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 <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093716.3198666-5-oswald.buddenhagen@gmx.de>
-
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 <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093716.3198666-4-oswald.buddenhagen@gmx.de>
-
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 <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093716.3198666-3-oswald.buddenhagen@gmx.de>
-
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: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093716.3198666-2-oswald.buddenhagen@gmx.de>
-
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: Takashi Iwai <tiwai@suse.de> Message-ID: <20240425233653.218434-1-o-takashi@sakamocchi.jp>
-
- 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: Ivan Orlov <ivan.orlov0322@gmail.com> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240425160754.114716-1-colin.i.king@gmail.com>
-
- 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: Takashi Iwai <tiwai@suse.de>
-
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 <sbinding@opensource.cirrus.com> Message-ID: <20240423162303.638211-3-sbinding@opensource.cirrus.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
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: Stefan Binding <sbinding@opensource.cirrus.com> Message-ID: <20240423162303.638211-2-sbinding@opensource.cirrus.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 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: Takashi Iwai <tiwai@suse.de>
-
- 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 <tiwai@suse.de>
-
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: Takashi Iwai <tiwai@suse.de>
-
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: Takashi Iwai <tiwai@suse.de>
-
- 18 Apr, 2024 14 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: Takashi Iwai <tiwai@suse.de>
-
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: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240416121726.628679-4-pavel.hofman@ivitera.com>
-
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 <pavel.hofman@ivitera.com> Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240416121726.628679-3-pavel.hofman@ivitera.com>
-
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: Pavel Hofman <pavel.hofman@ivitera.com> Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240416121726.628679-2-pavel.hofman@ivitera.com>
-
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: Takashi Iwai <tiwai@suse.de>
-
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: 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: Takashi Iwai <tiwai@suse.de>
-
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: Stefan Binding <sbinding@opensource.cirrus.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240411110813.330483-8-sbinding@opensource.cirrus.com>
-
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 <sbinding@opensource.cirrus.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240411110813.330483-7-sbinding@opensource.cirrus.com>
-
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 <sbinding@opensource.cirrus.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240411110813.330483-6-sbinding@opensource.cirrus.com>
-
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 <sbinding@opensource.cirrus.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240411110813.330483-5-sbinding@opensource.cirrus.com>
-
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 <sbinding@opensource.cirrus.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240411110813.330483-4-sbinding@opensource.cirrus.com>
-
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 <sbinding@opensource.cirrus.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240411110813.330483-3-sbinding@opensource.cirrus.com>
-
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: Stefan Binding <sbinding@opensource.cirrus.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240411110813.330483-2-sbinding@opensource.cirrus.com>
-
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: Takashi Iwai <tiwai@suse.de>
-