- 29 Mar, 2023 8 commits
-
-
Tom Rix authored
clang with W=1 reports sound/pci/asihpi/hpi6000.c:1256:6: error: variable 'loop_count' set but not used [-Werror,-Wunused-but-set-variable] u32 loop_count = 0; ^ This variable is not used so remove it. Signed-off-by:Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20230326205712.1358918-1-trix@redhat.comSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
Tasos Sahanidis authored
The macro for said register already exists, so just use it, to make the code more readable. Signed-off-by:
Tasos Sahanidis <tasos@tasossah.com> Link: https://lore.kernel.org/r/20230329043918.179352-1-tasos@tasossah.comSigned-off-by:
-
Tasos Sahanidis authored
There's no need to switch between unsigned short and u16, especially since all the functions that end up using old_legacy_ctrl specify u16 anyway. Signed-off-by:
-
Tasos Sahanidis authored
YMF744 and newer store the base IO ports in separate PCI config registers. Since these registers were not restored, when set to a non-default value, features that rely on them (FM, MPU401, gameport) were not functional after restore, as their respective IO ports were reset to their defaults. Signed-off-by:
-
Tasos Sahanidis authored
In preparation for storing more than two legacy PCI registers, the existing ones are moved into a new array. Signed-off-by:
-
Tasos Sahanidis authored
The registers were previously allocated when CONFIG_PM_SLEEP was set, however this only saved an insignificant amount of memory otherwise. Signed-off-by:
-
Tasos Sahanidis authored
Since commit 1a3c7bb0 ("PM: core: Add new *_PM_OPS macros, deprecate old ones") SIMPLE_DEV_PM_OPS has been marked deprecated. The intent is to remove CONFIG_PM_SLEEP guards for PM callbacks. As such the ifdefs are now removed. Signed-off-by:
-
Tasos Sahanidis authored
As an end user, it can be confusing to request an arbitrary IO port be used only to find out that it doesn't work without an obvious reason, especially since /sys/module/snd_ymfpci/parameters/{fm,joystick,mpu}_port indicate 0 after the module has been loaded. In my case, I was unaware that the YMF724 did not support such usage, and thus ended up spending time attempting to debug the issue. Now, when a user attempts to request an IO port that isn't supported by the hardware, the following message is printed: [ 25.549530] snd_ymfpci 0000:06:05.0: The Yamaha DS-1 (YMF724F) does not support arbitrary IO ports for FM (requested 0x1234) Signed-off-by:
-
- 24 Mar, 2023 8 commits
-
-
Takashi Iwai authored
Enhance the documents about the PCM, missing descriptions for a couple of helpers like snd_pcm_period_elapsed_under_stream_lock() and snd_pcm_stop_xrun(). Link: https://lore.kernel.org/r/20230323065237.5062-4-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Add a brief description about the newly added behavior of the PCM ack callback with -EPIPE error. Link: https://lore.kernel.org/r/20230323065237.5062-3-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
As PCM ack callback may handle the XRUN situation gracefully now, change the indirect PCM helpers to give a proper error (-EPIPE). Also, change the pointer callback helpers to deal with the XRUN error properly, too. This requires the PCM core change by the commit 8c721c53 ("ALSA: usb-audio: Fix recursive locking at XRUN during syncing"). Link: https://lore.kernel.org/r/20230323065237.5062-2-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Back-merge of 6.3 devel branch for further changes of PCM and documentation. Signed-off-by: -
Takashi Iwai authored
It's been reported that the recent kernel can't probe the PCM devices on Roland VS-100 properly, and it turned out to be a regression by the recent addition of the bit shift range check for the format bits. In the old code, we just did bit-shift and it resulted in zero, which is then corrected to the standard PCM format, while the new code explicitly returns an error in such a case. For addressing the regression, relax the check and fallback to the standard PCM type (with the info output). Fixes: 43d5ca88 ("ALSA: usb-audio: Fix potential out-of-bounds shift") Cc: <stable@vger.kernel.org> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217084 Link: https://lore.kernel.org/r/20230324075005.19403-1-tiwai@suse.deSigned-off-by:
-
Tom Rix authored
clang with W=1 reports sound/pci/rme9652/hdspm.c:6149:19: error: unused function 'copy_u32_le' [-Werror,-Wunused-function] static inline int copy_u32_le(void __user *dest, void __iomem *src) ^ This function is not used so remove it. Signed-off-by: -
Mark Brown authored
When reporting errors or skips we currently include the diagnostic message indicating why we're failing or skipping. This isn't ideal since KTAP defines the entire print as the test name, so if there's an error then test systems won't detect the test as being the same one as a passing test. Move the diagnostic to a separate ksft_print_msg() to avoid this issue, the test name part will always be the same for passes, fails and skips and the diagnostic information is still displayed. Signed-off-by:
Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230323-alsa-pcm-test-names-v1-1-8be67a8885ff@kernel.orgSigned-off-by:
-
Mark Brown authored
While it is common for driver bugs with events to apply to all events there are some issues which only trigger for specific values. Understanding these is easier if we know what we were trying to do when configuring the control so add logging for the specific values involved in the spurious event. Signed-off-by:
-
- 22 Mar, 2023 1 commit
-
-
Jaroslav Kysela authored
Unfortunately, in commit 5911d78f a wrong codec patch was selected. The model=alc283-dac-wcaps is equivalent to ALC283_FIXUP_CHROME_BOOK not ALC295_FIXUP_CHROME_BOOK. Fixes: 5911d78f ("ALSA: hda/realtek: Improve support for Dell Precision 3260") Signed-off-by:
Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20230322153404.386473-1-perex@perex.czSigned-off-by:
-
- 21 Mar, 2023 2 commits
-
-
Takashi Iwai authored
The recent support of low latency playback in USB-audio driver made the snd_usb_queue_pending_output_urbs() function to be called via PCM ack ops. In the new code path, the function is performed already in the PCM stream lock. The problem is that, when an XRUN is detected, the function calls snd_pcm_xrun() to notify, but snd_pcm_xrun() is supposed to be called only outside the stream lock. As a result, it leads to a deadlock of PCM stream locking. For avoiding such a recursive locking, this patch adds an additional check to the code paths in PCM core that call the ack callback; now it checks the error code from the callback, and if it's -EPIPE, the XRUN is handled in the PCM core side gracefully. Along with it, the USB-audio driver code is changed to follow that, i.e. -EPIPE is returned instead of the explicit snd_pcm_xrun() call when the function is performed already in the stream lock. Fixes: d5f871f8 ("ALSA: usb-audio: Improved lowlatency playback support") Reported-and-tested-by:
John Keeping <john@metanate.com> Link: https://lore.kernel.org/r/20230317195128.3911155-1-john@metanate.comReviewed-by:
-
Takashi Iwai authored
The recent commit f83bb259 ("ALSA: hda/conexant: Add quirk for LENOVO 20149 Notebook model") introduced a quirk for the device with 17aa:3977, but this caused a regression on another model (Lenovo Ideadpad U31) with the very same PCI SSID. And, through skimming over the net, it seems that this PCI SSID is used for multiple different models, so it's no good idea to apply the quirk with the SSID. Although we may take a different ID check (e.g. the codec SSID instead of the PCI SSID), unfortunately, the original patch author couldn't identify the hardware details any longer as the machine was returned, and we can't develop the further proper fix. In this patch, instead, we partially revert the change so that the quirk won't be applied as default for addressing the regression. Meanwhile, the quirk function itself is kept, and it's now made to be applicable via the explicit model=lenovo-20149 option. Fixes: f83bb259 ("ALSA: hda/conexant: Add quirk for LENOVO 20149 Notebook model") Reported-by:
Jetro Jormalainen <jje-lxkl@jetro.fi> Link: https://lore.kernel.org/r/20230308215009.4d3e58a6@mopti Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20230320140954.31154-1-tiwai@suse.deSigned-off-by:
-
- 20 Mar, 2023 1 commit
-
-
Lizhe authored
If there is no driver match function, the driver core assumes that each candidate pair (driver, device) matches, see driver_match_device() Drop the bus's match function that always returned 1 and so implements the same behaviour as when there is no match function. Signed-off-by:
Lizhe <sensor1010@163.com> Link: https://lore.kernel.org/r/20230319044733.327091-1-sensor1010@163.comSigned-off-by:
-
- 19 Mar, 2023 3 commits
-
-
Tom Rix authored
clang with W=1 reports sound/drivers/portman2x4.c:185:18: error: unused function 'portman_read_command' [-Werror,-Wunused-function] static inline u8 portman_read_command(struct portman *pm) ^ sound/drivers/portman2x4.c:195:18: error: unused function 'portman_read_data' [-Werror,-Wunused-function] static inline u8 portman_read_data(struct portman *pm) ^ These static functions are not used, so remove them. Signed-off-by: -
Tom Rix authored
clang with W=1 reports sound/pci/ymfpci/ymfpci_main.c:34:18: error: unused function 'snd_ymfpci_readb' [-Werror,-Wunused-function] static inline u8 snd_ymfpci_readb(struct snd_ymfpci *chip, u32 offset) ^ This static function is not used, so remove it. Signed-off-by: -
Tim Crawford authored
Add the audio quirk for some of Clevo's latest RPL laptops: - NP50RNJS (ALC256) - NP70SNE (ALC256) - PD50SNE (ALC1220) - PE60RNE (ALC1220) Co-authored-by:
Jeremy Soller <jeremy@system76.com> Signed-off-by:
Tim Crawford <tcrawford@system76.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20230317141825.11807-1-tcrawford@system76.comSigned-off-by:
-
- 14 Mar, 2023 3 commits
-
-
Kuninori Morimoto authored
tuning_ctl_set() might have buffer overrun at (X) if it didn't break from loop by matching (A). static int tuning_ctl_set(...) { for (i = 0; i < TUNING_CTLS_COUNT; i++) (A) if (nid == ca0132_tuning_ctls[i].nid) break; snd_hda_power_up(...); (X) dspio_set_param(..., ca0132_tuning_ctls[i].mid, ...); snd_hda_power_down(...); ^ return 1; } We will get below error by cppcheck sound/pci/hda/patch_ca0132.c:4229:2: note: After for loop, i has value 12 for (i = 0; i < TUNING_CTLS_COUNT; i++) ^ sound/pci/hda/patch_ca0132.c:4234:43: note: Array index out of bounds dspio_set_param(codec, ca0132_tuning_ctls[i].mid, 0x20, ^ This patch cares non match case. Signed-off-by:Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87sfe9eap7.wl-kuninori.morimoto.gx@renesas.comSigned-off-by:
-
Kuninori Morimoto authored
control_message() might be called with pao = NULL. Here indicates control_message() as sample. (B) static void control_message(struct hpi_adapter_obj *pao, ...) { ^^^ struct hpi_hw_obj *phw = pao->priv; ... ^^^ } (A) void _HPI_6205(struct hpi_adapter_obj *pao, ...) { ^^^ ... case HPI_OBJ_CONTROL: (B) control_message(pao, phm, phr); break; ^^^ ... } void HPI_6205(...) { ... (A) _HPI_6205(NULL, phm, phr); ... ^^^^ } Therefore, We will get too many warning via cppcheck, like below sound/pci/asihpi/hpi6205.c:238:27: warning: Possible null pointer dereference: pao [nullPointer] struct hpi_hw_obj *phw = pao->priv; ^ sound/pci/asihpi/hpi6205.c:433:13: note: Calling function '_HPI_6205', 1st argument 'NULL' value is 0 _HPI_6205(NULL, phm, phr); ^ sound/pci/asihpi/hpi6205.c:401:20: note: Calling function 'control_message', 1st argument 'pao' value is 0 control_message(pao, phm, phr); ^ Set phr->error like many functions doing, and don't call _HPI_6205() with NULL. Signed-off-by: -
Ruslan Bilovol authored
Wireless USB host controller support has been removed from Linux Kernel more than 3 years ago in commit caa6772d ("Staging: remove wusbcore and UWB from the kernel tree."), and the associated code in the snd-usb-audio driver became unused and untested. If in the future somebody will return WUSB/UWB support back to the kernel, the snd-usb-audio driver will reject Wireless USB audio devices at probe stage, and this patch should be reverted. Signed-off-by:
Ruslan Bilovol <ruslan.bilovol@gmail.com> Link: https://lore.kernel.org/r/20230312222857.296623-1-ruslan.bilovol@gmail.comSigned-off-by:
-
- 10 Mar, 2023 1 commit
-
-
Takashi Iwai authored
Merge tag 'asoc-fix-v6.3-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v6.3 More fixes that came in since -rc1, a lot from Intel - looks like they've been busy test. Everything is driver specific.
-
- 09 Mar, 2023 1 commit
-
-
Emil Abildgaard Svendsen authored
Currently only one stream is supported. This isn't usally a problem until you have a multi codec audio card. Because the audio card will run startup and shutdown on both capture and playback streams. So if your hdmi-codec only support either playback or capture. Then ALSA can't open for playback and capture. This patch will ignore if startup and shutdown are called with a non supported stream. Thus, allowing an audio card like this: +-+ cpu1 <--@-| |-> codec1 (HDMI-CODEC) | |<- codec2 (NOT HDMI-CODEC) +-+ Signed-off-by:Emil Svendsen <emas@bang-olufsen.dk> Link: https://lore.kernel.org/r/20230309065432.4150700-2-emas@bang-olufsen.dkSigned-off-by:
-
- 08 Mar, 2023 8 commits
-
-
Guenter Roeck authored
The following traceback is reported if mutex debugging is enabled. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 0 PID: 17 at kernel/locking/mutex.c:950 __mutex_lock_common+0x31c/0x11d4 Modules linked in: CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 5.10.172-lockdep-21846-g849884cfca5a #1 fd2de466502012eb58bc8beb467f07d0b925611f Hardware name: MediaTek kakadu rev0/rev1 board (DT) Workqueue: events da7219_aad_jack_det_work pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--) pc : __mutex_lock_common+0x31c/0x11d4 lr : __mutex_lock_common+0x31c/0x11d4 sp : ffffff80c0317ae0 x29: ffffff80c0317b50 x28: ffffff80c0317b20 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000100000000 x23: ffffffd0121d296c x22: dfffffd000000000 x21: 0000000000000000 x20: 0000000000000000 x19: ffffff80c73d7190 x18: 1ffffff018050f52 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000001 x11: 0000000000000000 x10: 0000000000000000 x9 : 83f0d991da544b00 x8 : 83f0d991da544b00 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffffff80c03176a0 x4 : 0000000000000000 x3 : ffffffd01067fd78 x2 : 0000000100000000 x1 : ffffff80c030ba80 x0 : 0000000000000028 Call trace: __mutex_lock_common+0x31c/0x11d4 mutex_lock_nested+0x98/0xac da7219_aad_jack_det_work+0x54/0xf0 process_one_work+0x6cc/0x19dc worker_thread+0x458/0xddc kthread+0x2fc/0x370 ret_from_fork+0x10/0x30 irq event stamp: 579 hardirqs last enabled at (579): [<ffffffd012442b30>] exit_to_kernel_mode+0x108/0x138 hardirqs last disabled at (577): [<ffffffd010001144>] __do_softirq+0x53c/0x125c softirqs last enabled at (578): [<ffffffd01009995c>] __irq_exit_rcu+0x264/0x4f4 softirqs last disabled at (573): [<ffffffd01009995c>] __irq_exit_rcu+0x264/0x4f4 ---[ end trace 26da674636181c40 ]--- Initialize the mutex to fix the problem. Cc: David Rau <David.Rau.opensource@dm.renesas.com> Fixes: 7fde88ed ("ASoC: da7219: Improve the IRQ process to increase the stability") Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20230307155111.1985522-1-linux@roeck-us.netSigned-off-by:
-
Bjorn Helgaas authored
CONTROLLER_IN_GPU() is clearly intended to match only Intel devices, but previously it checked only the PCI Device ID, not the Vendor ID, so it could match devices from other vendors that happened to use the same Device ID. Update CONTROLLER_IN_GPU() so it matches only Intel devices. Fixes: 535115b5 ("ALSA: hda - Abort the probe without i915 binding for HSW/B") Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20230307214054.886721-1-helgaas@kernel.orgSigned-off-by:
-
Hamidreza H. Fard authored
Samsung Galaxy Book2 Pro (13" 2022 NP930XED-KA1DE) with codec SSID 144d:c868 requires the same workaround for enabling the speaker amp like other Samsung models with ALC298 code. Signed-off-by:
Hamidreza H. Fard <nitocris@posteo.net> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20230307163741.3878-1-nitocris@posteo.netSigned-off-by:
-
Jeremy Szu authored
There is a HP platform needs ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED quirk to make mic-mute/audio-mute/speaker working. Signed-off-by:
Jeremy Szu <jeremy.szu@canonical.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20230307135317.37621-1-jeremy.szu@canonical.comSigned-off-by:
-
Bard Liao authored
Use SOF as default audio driver. Signed-off-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by:
Gongjun Song <gongjun.song@intel.com> Reviewed-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20230306074101.3906707-1-yung-chuan.liao@linux.intel.comSigned-off-by:
-
Mark Brown authored
It can be helpful to know which card numbers apply to which cards in a multi-card system so log the card names when we start the test programs. People looking at the logs may not have direct access to the systems being tested. Signed-off-by:
-
Mark Brown authored
Currently we only log the names of controls on error but it can be useful to know what control we're testing (for example, when looking at why the tests are taking a while to run). People looking at test logs may not have direct access to the target system. This will increase the amount we write to the console, hopefully that's buffered. Signed-off-by:
-
Mark Brown authored
If a control has an invalid default value then we might fail to set it when restoring the default value after our write tests, for example due to correctly implemented range checks in put() operations. Currently this causes us to report the tests we were running as failed even when the operation we were trying to test is successful, making it look like there are problems where none really exist. Stop doing this, only reporting any issues during the actual test. We already have validation for the initial readback being in spec and for writing the default value back so failed tests will be reported for these controls, and we log an error on the operation that failed when we write so there will be a diagnostic warning the user that there is a problem. Signed-off-by:
-
- 07 Mar, 2023 4 commits
-
-
Mark Brown authored
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>: We have recently noticed that the ops_free callback was missed for the device descriptions on Intel platforms.
-
Rander Wang authored
Recent firmware changes modified the curve duration from 32 to 64 bits, which breaks volume ramps. A simple solution would be to change the definition, but unfortunately the ASoC topology framework only supports up to 32 bit tokens. This patch suggests breaking the 64 bit value in low and high parts, with only the low-part extracted from topology and high-part only zeroes. Since the curve duration is represented in hundred of nanoseconds, we can still represent a 400s ramp, which is just fine. The defacto ABI change has no effect on existing users since the IPC4 firmware has not been released just yet. Link: https://github.com/thesofproject/linux/issues/4026Signed-off-by:
Rander Wang <rander.wang@intel.com> Reviewed-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by:
Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by:
-
Pierre-Louis Bossart authored
When an IPC error happens while setting-up a widget during the FE hw_params phase, the existing logic will unwind all previous configurations but will overwrite the return status. The ALSA/ASoC logic will then proceed with the prepare and trigger phases, even though the firmware resources are not available. Fix by returning the initial error code and ignoring the code returned in the UNPREPARE phase. Signed-off-by:
Chao Song <chao.song@linux.intel.com> Reviewed-by:
-
Pierre-Louis Bossart authored
This reverts commit a09d82ce ("ASoC: SOF: Intel: hda-ctrl: remove useless sleep") It was a mistake to remove those delays, in light of comments in the HDaudio spec captured in snd_hdac_bus_reset_link() that the codec needs time for its initialization and PLL lock. Signed-off-by:
-
