- 28 Apr, 2024 10 commits
-
-
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 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:
-
- 19 Apr, 2024 2 commits
-
-
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 4 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:
-
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:
-
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:
-
- 07 Apr, 2024 2 commits
-
-
Shenghao Ding authored
Calibrated data was written into an incorrect register, which cause speaker protection sometimes malfuctions Fixes: 5be27f1e ("ALSA: hda/tas2781: Add tas2781 HDA driver") Signed-off-by:
-
Vitaly Rodionov authored
Add support for HP SnowWhite laptops with CS35L51 amplifiers on I2C bus connected to Realtek codec. Signed-off-by:
Vitaly Rodionov <vitalyr@opensource.cirrus.com> Message-ID: <20240405210635.22193-1-vitalyr@opensource.cirrus.com> Signed-off-by:
-
- 05 Apr, 2024 1 commit
-
-
Takashi Iwai authored
Merge tag 'asoc-fix-v6.9-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v6.9 A relatively large set of fixes here, the biggest piece of it is a series correcting some problems with the delay reporting for Intel SOF cards but there's a bunch of other things. Everything here is driver specific except for a fix in the core for an issue with sign extension handling volume controls.
-
- 04 Apr, 2024 2 commits
-
-
Chaitanya Kumar Borah authored
In cases where the sof driver is unable to find the firmware and/or topology file [1], it exits without releasing the i915 runtime pm wakeref [2]. This results in dmesg warnings[3] during suspend/resume or driver unbind. Add remove_late() to the failure path of sof_init_environment so that i915 wakeref is released appropriately [1] [ 8.990366] sof-audio-pci-intel-mtl 0000:00:1f.3: SOF firmware and/or topology file not found. [ 8.990396] sof-audio-pci-intel-mtl 0000:00:1f.3: Supported default profiles [ 8.990398] sof-audio-pci-intel-mtl 0000:00:1f.3: - ipc type 1 (Requested): [ 8.990399] sof-audio-pci-intel-mtl 0000:00:1f.3: Firmware file: intel/sof-ipc4/mtl/sof-mtl.ri [ 8.990401] sof-audio-pci-intel-mtl 0000:00:1f.3: Topology file: intel/sof-ace-tplg/sof-mtl-rt711-2ch.tplg [ 8.990402] sof-audio-pci-intel-mtl 0000:00:1f.3: Check if you have 'sof-firmware' package installed. [ 8.990403] sof-audio-pci-intel-mtl 0000:00:1f.3: Optionally it can be manually downloaded from: [ 8.990404] sof-audio-pci-intel-mtl 0000:00:1f.3: https://github.com/thesofproject/sof-bin/ [ 8.999088] sof-audio-pci-intel-mtl 0000:00:1f.3: error: sof_probe_work failed err: -2 [2] ref_tracker: 0000:00:02.0@ffff9b8511b6a378 has 1/5 users at track_intel_runtime_pm_wakeref.part.0+0x36/0x70 [i915] __intel_runtime_pm_get+0x51/0xb0 [i915] intel_runtime_pm_get+0x17/0x20 [i915] intel_display_power_get+0x2f/0x70 [i915] i915_audio_component_get_power+0x23/0x120 [i915] snd_hdac_display_power+0x89/0x130 [snd_hda_core] hda_codec_i915_init+0x3f/0x50 [snd_sof_intel_hda] hda_dsp_probe_early+0x170/0x250 [snd_sof_intel_hda_common] snd_sof_device_probe+0x224/0x320 [snd_sof] sof_pci_probe+0x15b/0x220 [snd_sof_pci] hda_pci_intel_probe+0x30/0x70 [snd_sof_intel_hda_common] local_pci_probe+0x4c/0xb0 pci_device_probe+0xcc/0x250 really_probe+0x18e/0x420 __driver_probe_device+0x7e/0x170 driver_probe_device+0x23/0xa0 [3] [ 484.105070] ------------[ cut here ]------------ [ 484.108238] thunderbolt 0000:00:0d.2: PM: pci_pm_suspend_late+0x0/0x50 returned 0 after 0 usecs [ 484.117106] i915 0000:00:02.0: i915 raw-wakerefs=1 wakelocks=1 on cleanup [ 484.792005] WARNING: CPU: 2 PID: 2405 at drivers/gpu/drm/i915/intel_runtime_pm.c:444 intel_runtime_pm_driver_release+0x6c/0x80 Tested-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by:
Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by:
Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Acked-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://github.com/thesofproject/linux/pull/4878Signed-off-by:
Mark Brown <broonie@kernel.org>
-
Vijendar Mukunda authored
Before ACP firmware loading, DSP interrupts are not expected. Sometimes after reboot, it's observed that before ACP firmware is loaded false DSP interrupt is reported. Registering the interrupt handler before acp initialization causing false interrupts sometimes on reboot as ACP reset is not applied. Correct the sequence by invoking acp initialization sequence prior to registering interrupt handler. Fixes: 738a2b5e ("ASoC: SOF: amd: Add IPC support for ACP IP block") Signed-off-by:
Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://msgid.link/r/20240404041717.430545-1-Vijendar.Mukunda@amd.comSigned-off-by:
-
- 03 Apr, 2024 2 commits
-
-
Peter Ujfalusi authored
During probe the DMIC/SSP offload is enabled and it is not reversed on remove. Add a remove wrapper for LNL to disable the offload for DMIC and SSP similarly to what is done during probe. Signed-off-by:
-
Mark Brown authored
This v6.8 change didn't make it into the release, send it as a fix for v6.9.
-
- 02 Apr, 2024 11 commits
-
-
Mark Brown authored
Merge series from Zhang Yi <zhangyi@everest-semi.com>: We solved some issues related to headphone detection.And for using the same configuration in different power conditions,we modified the clock table
-
Amadeusz Sławiński authored
Modpost warns about missing module description, add it. Reviewed-by:
Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by:
Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Link: https://msgid.link/r/20240402130640.3310999-1-amadeuszx.slawinski@linux.intel.comSigned-off-by:
-
Zhang Yi authored
We removed the configuration of ES8326_ADC_SCALE in es8326_jack_detect_handler because user changed the configuration by snd_controls Signed-off-by:
Zhang Yi <zhangyi@everest-semi.com> Link: https://msgid.link/r/20240402062043.20608-5-zhangyi@everest-semi.comSigned-off-by:
-
Zhang Yi authored
We got a headphone detection issue after suspend and resume. And we fixed it by modifying the configuration at es8326_suspend and invoke es8326_irq at es8326_resume. Signed-off-by:
-
Zhang Yi authored
We got a digital microphone feature issue. And we fixed it by modifying the clock table. Also, we changed the marco ES8326_CLK_ON declaration Signed-off-by:
-
Zhang Yi authored
We got an error report about headphone type detection and button detection. We fixed the headphone type detection error by adjusting the debounce timer configuration. And we fixed the button detection error by disabling the button detection feature when the headphone are unplugged and enabling it when headphone are plugged in. Signed-off-by:
-
Takashi Iwai authored
For shutting up spurious KMSAN uninit-value warnings, just replace kmalloc() calls with kzalloc() for the buffers used for communications. There should be no real issue with the original code, but it's still better to cover. Reported-by: syzbot+7fb05ccf7b3d2f9617b3@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/00000000000084b18706150bcca5@google.com Message-ID: <20240402063628.26609-1-tiwai@suse.de> Signed-off-by:
-
Luke D. Jones authored
Fixes the realtek quirk to initialise the Cirrus amp correctly and adds related quirk for missing DSD properties. This model laptop has slightly updated internals compared to the previous version with Realtek Codec ID of 0x1caf. Signed-off-by:
-
I Gede Agastya Darma Laksana authored
This patch addresses an issue with the Panasonic CF-SZ6's existing quirk, specifically its headset microphone functionality. Previously, the quirk used ALC269_FIXUP_HEADSET_MODE, which does not support the CF-SZ6's design of a single 3.5mm jack for both mic and audio output effectively. The device uses pin 0x19 for the headset mic without jack detection. Following verification on the CF-SZ6 and discussions with the original patch author, i determined that the update to ALC269_FIXUP_ASPIRE_HEADSET_MIC is the appropriate solution. This change is custom-designed for the CF-SZ6's unique hardware setup, which includes a single 3.5mm jack for both mic and audio output, connecting the headset microphone to pin 0x19 without the use of jack detection. Fixes: 0fca97a2 ("ALSA: hda/realtek - Add Panasonic CF-SZ6 headset jack quirk") Signed-off-by:
I Gede Agastya Darma Laksana <gedeagas22@gmail.com> Cc: <stable@vger.kernel.org> Message-ID: <20240401174602.14133-1-gedeagas22@gmail.com> Signed-off-by:
-
Christian Bendiksen authored
This fixes the sound not working from internal speakers on Lenovo Legion Slim 7 16ARHA7 models. The correct subsystem ID have been added to cs35l41_hda_property.c and patch_realtek.c. Signed-off-by:
Christian Bendiksen <christian@bendiksen.me> Cc: <stable@vger.kernel.org> Message-ID: <20240401122603.6634-1-christian@bendiksen.me> Signed-off-by:
-
Oswald Buddenhagen authored
As already anticipated in the original commit, playback was broken for very short samples. I just didn't expect it to be an actual problem, because we're talking about less than 1.5 milliseconds here. But clearly such wavetable samples do actually exist. The problem was that for such short samples we'd set the current position beyond the end of the loop, so we'd run off the end of the sample and play garbage. This is a bigger (more audible) problem than the original one, which was that we'd start playback with garbage (whatever was still in the cache), which would be mostly masked by the note's attack phase. So revert to the old behavior for now. We'll subsequently fix it properly with a bigger patch series. Note that this isn't a full revert - the dead code is not re-introduced, because that would be silly. Fixes: df335e9a ("ALSA: emu10k1: fix synthesizer sample playback position and caching") Link: https://bugzilla.kernel.org/show_bug.cgi?id=218625Signed-off-by:
-
- 01 Apr, 2024 1 commit
-
-
Uwe Kleine-König authored
As described in the added code comment, a reference to .exit.text is ok for drivers registered via module_platform_driver_probe(). Make this explicit to prevent the following section mismatch warning WARNING: modpost: sound/oss/dmasound/dmasound_paula: section mismatch in reference: amiga_audio_driver+0x8 (section: .data) -> amiga_audio_remove (section: .exit.text) that triggers on an allmodconfig W=1 build. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Message-ID: <c216a129aa88f3af5c56fe6612a472f7a882f048.1711748999.git.u.kleine-koenig@pengutronix.de> Signed-off-by:
-
- 30 Mar, 2024 1 commit
-
-
Simon Trimmer authored
These ASUS laptops use the Realtek HDA codec combined with a number of CS35L56 amplifiers. The SSID of the GA403U matches a previous ASUS laptop - we can tell them apart because they use different codecs. Signed-off-by:
Simon Trimmer <simont@opensource.cirrus.com> Message-ID: <20240329112803.23897-1-simont@opensource.cirrus.com> Signed-off-by:
-
- 29 Mar, 2024 3 commits
-
-
Vijendar Mukunda authored
If acp_init() fails, acp pci driver probe should return error. Add acp_init() function return value check logic. Fixes: e61b4155 ("ASoC: amd: acp: refactor the acp init and de-init sequence") Signed-off-by:
-
Gergo Koteles authored
Since we put dvc_tlv static variable to a header file it's copied to each module that includes the header. But not all of them are actually used it. Fix this W=1 build warning: include/sound/tas2781-tlv.h:18:35: warning: 'dvc_tlv' defined but not used [-Wunused-const-variable=] Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202403290354.v0StnRpc-lkp@intel.com/ Fixes: ae065d0c ("ALSA: hda/tas2781: remove digital gain kcontrol") Signed-off-by:
Gergo Koteles <soyer@irl.hu> Message-ID: <0e461545a2a6e9b6152985143e50526322e5f76b.1711665731.git.soyer@irl.hu> Signed-off-by:
-
Mark Brown authored
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>: Fix a set of problematic locking sequences and update error messages, tested on SOF/SoundWire platforms.
-
- 28 Mar, 2024 1 commit
-
-
Stephen Lee authored
In snd_soc_info_volsw(), mask is generated by figuring out the index of the most significant bit set in max and converting the index to a bitmask through bit shift 1. Unintended wraparound occurs when max is an integer value with msb bit set. Since the bit shift value 1 is treated as an integer type, the left shift operation will wraparound and set mask to 0 instead of all 1's. In order to fix this, we type cast 1 as `1ULL` to prevent the wraparound. Fixes: 7077148f ("ASoC: core: Split ops out of soc-core.c") Signed-off-by:
Stephen Lee <slee08177@gmail.com> Link: https://msgid.link/r/20240326010131.6211-1-slee08177@gmail.comSigned-off-by:
-
