- 04 May, 2020 3 commits
-
-
Sameer Pujar authored
Tegra194 has 4 SDO lines and with this configuration playback fails for 44.1K/48K, 2-channel and 16-bps. It results in below print, "aplay: pcm_write:2011: write error: Input/output error" Below relation is used to derive stripe control and is referenced from HD Audio Specification: Revision 1.0a. { ((num_channels * bits_per_sample) / number of SDOs) >= 8 } Due to a legacy HW design problem, playback issue is hit while using a stripe value resulting from above formula when ratio is '8'. Thus it is recommended that the ratio must be greater than '8'. Since the number of SDO lines is in powers of 2, next available ratio '16' is used as a limiting factor on Tegra194 to workaround the problem. Signed-off-by: Sameer Pujar <spujar@nvidia.com> Link: https://lore.kernel.org/r/1588580176-2801-4-git-send-email-spujar@nvidia.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Sameer Pujar authored
Stripe control programming is governed by following formula, which is referenced from the HD Audio specification(Revision 1.0a). { ((num_channels * bits_per_sample) / number of SDOs) >= 8 } Currently above is implemented in snd_hdac_get_stream_stripe_ctl(). This patch introduces a structure member to store the default factor of '8'. If any HW wants to use a different value, this member can be easily updated. Signed-off-by: Sameer Pujar <spujar@nvidia.com> Link: https://lore.kernel.org/r/1588580176-2801-3-git-send-email-spujar@nvidia.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Sameer Pujar authored
Tegra194 supports 4 SDO lines but GCAP register indicates 2 lines. Thus it does not reflect the true capability of the HW. This patch presents a workaround by updating NSDO value accordingly in T_AZA_DBG_CFG_2 register. Signed-off-by: Sameer Pujar <spujar@nvidia.com> Link: https://lore.kernel.org/r/1588580176-2801-2-git-send-email-spujar@nvidia.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 02 May, 2020 2 commits
-
-
Vasily Khoruzhick authored
At least POD HD500 uses message-based communication, both sides can send messages. Add poll callback so application can wait for device messages without using busy loop. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Link: https://lore.kernel.org/r/20200502193120.79115-3-anarsoul@gmail.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Vasily Khoruzhick authored
Currently line6 hwdep interface ignores O_NONBLOCK flag when opening device and it renders it somewhat useless when using poll. Check for O_NONBLOCK flag when opening device and don't block read() if it is set. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Link: https://lore.kernel.org/r/20200502193120.79115-2-anarsoul@gmail.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 01 May, 2020 2 commits
-
-
Dan Carpenter authored
The "header->number" comes from the ioctl and it needs to be clamped to prevent out of bounds writes. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20200501094011.GA960082@mwandaSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Cover with a proper ifdef around the variable declaration for fixing the following compilation warning without CONFIG_LEDS_TRIGGER_AUDIO: sound/pci/hda/patch_realtek.c: In function 'alc_fixup_hp_gpio_led': sound/pci/hda/patch_realtek.c:4134:6: warning: unused variable 'err' [-Wunused-variable] Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 87dc3648 ("ALSA: hda/realtek - Add LED class support for micmute LED") Link: https://lore.kernel.org/r/20200501072857.13720-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 30 Apr, 2020 3 commits
-
-
Kai-Heng Feng authored
Currently DMIC controls micmute LED via "audio mute LED trigger". However, unlike Dell and Lenovo platforms, HP platforms don't provide a way to control micmute LED via ACPI, it's controlled by HDA codec instead. So let's register an LED class for micmute so other subsystems like DMIC can facilitate the codec-controlled LED. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20200430135209.14703-1-kai.heng.feng@canonical.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Kai-Heng Feng authored
Though the system uses DMIC, headset mic still uses the HDA, let's use GPIO 0x1 to control the micmute LED. The micmute LED GPIO has a different polarity to the mute LED GPIO, we can use the newly added micmute_led_polarity to indicate that. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20200430083255.5093-2-kai.heng.feng@canonical.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Kai-Heng Feng authored
Currently mute LED and micmute LED share the same GPIO polarity. So split the polarity for mute and micmute, in case they have different polarities. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20200430083255.5093-1-kai.heng.feng@canonical.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 29 Apr, 2020 1 commit
-
-
YueHaibing authored
There's no callers in-tree. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20200429132805.18712-1-yuehaibing@huawei.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 24 Apr, 2020 7 commits
-
-
Takashi Iwai authored
The linked list entry from FIFO is peeked at queue_pending_output_urbs() but the actual element pop-out is performed outside the spinlock, and it's potentially racy. Do delete the link at the right place inside the spinlock. Fixes: 8fdff6a3 ("ALSA: snd-usb: implement new endpoint streaming model") Link: https://lore.kernel.org/r/20200424074016.14301-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Alexander Tsoy authored
Frame size computation has been fixed and the workaround is no longer needed. Signed-off-by: Alexander Tsoy <alexander@tsoy.me> Link: https://lore.kernel.org/r/20200424022449.14972-2-alexander@tsoy.meSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Alexander Tsoy authored
For computation of the the next frame size current value of fs/fps and accumulated fractional parts of fs/fps are used, where values are stored in Q16.16 format. This is quite natural for computing frame size for asynchronous endpoints driven by explicit feedback, since in this case fs/fps is a value provided by the feedback endpoint and it's already in the Q format. If an error is accumulated over time, the device can adjust fs/fps value to prevent buffer overruns/underruns. But for synchronous endpoints the accuracy provided by these computations is not enough. Due to accumulated error the driver periodically produces frames with incorrect size (+/- 1 audio sample). This patch fixes this issue by implementing a different algorithm for frame size computation. It is based on accumulating of the remainders from division fs/fps and it doesn't accumulate errors over time. This new method is enabled for synchronous and adaptive playback endpoints. Signed-off-by: Alexander Tsoy <alexander@tsoy.me> Link: https://lore.kernel.org/r/20200424022449.14972-1-alexander@tsoy.meSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Back-merge 5.7-rc devel branch for further changes. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The commit 3c6fd1f0 ("ALSA: hda: Add driver blacklist") added a new blacklist for the devices that are known to have empty codecs, and one of the entries was ASUS ROG Zenith II (PCI SSID 1043:874f). However, it turned out that the very same PCI SSID is used for the previous model that does have the valid HD-audio codecs and the change broke the sound on it. Since the empty codec problem appear on the certain AMD platform (PCI ID 1022:1487), this patch changes the blacklist matching to both PCI ID and SSID using pci_match_id(). Also, the entry that was removed by the previous fix for ASUS ROG Zenigh II is re-added. Link: https://lore.kernel.org/r/20200424061222.19792-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Merge NHLT init cleanup. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Cezary Rojewski authored
NHLT fetch based on _DSM prevents ACPI table override mechanism from being utilized. Make use of acpi_get_table to enable it and get rid of redundant code. In consequence, NHLT can be overridden just like any other ACPI table, e.g.: DSDT or SSDT. Change has been verified on all Intel AVS architecture platforms, RVP and production laptops both. Change possible due to addition of NHLT signature to the list of standard ACPI tables: https://patchwork.kernel.org/patch/11463235/ Override helps not only with debug purposes but also allows user for table adjustment when one found on their production hardware is invalid. Shared official NHLT spec is now available to community at: https://01.org/blogs/intel-smart-sound-technology-audio-dsp NHLT support for iASL is still ongoing subject but should be available in nearest future. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20200423160310.28019-1-cezary.rojewski@intel.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 23 Apr, 2020 3 commits
-
-
Takashi Iwai authored
HD-audio codec driver applies a tricky procedure to forcibly perform the runtime resume by mimicking the usage count even if the device has been runtime-suspended beforehand. This was needed to assure to trigger the jack detection update after the system resume. And recently we also applied the similar logic to the HD-audio controller side. However this seems leading to some inconsistency, and eventually PCI controller gets screwed up. This patch is an attempt to fix and clean up those behavior: instead of the tricky runtime resume procedure, the existing jackpoll work is scheduled when such a forced codec resume is required. The jackpoll work will power up the codec, and this alone should suffice for the jack status update in usual cases. If the extra polling is requested (by checking codec->jackpoll_interval), the manual update is invoked after that, and the codec is powered down again. Also, we filter the spurious wake up of the codec from the controller runtime resume by checking codec->relaxed_resume flag. If this flag is set, basically we don't need to wake up explicitly, but it's supposed to be done via the audio component notifier. Fixes: c4c8dd6e ("ALSA: hda: Skip controller resume if not needed") Link: https://lore.kernel.org/r/20200422203744.26299-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Kailang Yang authored
Enable new codec supported for ALC245. Signed-off-by: Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/8c0804738b2c42439f59c39c8437817f@realtek.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Xiyu Yang authored
snd_microii_spdif_default_get() invokes snd_usb_lock_shutdown(), which increases the refcount of the snd_usb_audio object "chip". When snd_microii_spdif_default_get() returns, local variable "chip" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in several exception handling paths of snd_microii_spdif_default_get(). When those error scenarios occur such as usb_ifnum_to_if() returns NULL, the function forgets to decrease the refcnt increased by snd_usb_lock_shutdown(), causing a refcnt leak. Fix this issue by jumping to "end" label when those error scenarios occur. Fixes: 447d6275 ("ALSA: usb-audio: Add sanity checks for endpoint accesses") Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn> Signed-off-by: Xin Tan <tanxin.ctf@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1587617711-13200-1-git-send-email-xiyuyang19@fudan.edu.cnSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 22 Apr, 2020 3 commits
-
-
Takashi Iwai authored
It turned out that ALC1220-VB USB-audio device gives the interrupt event to some PCM terminals while those don't allow the connector state request but only the actual I/O terminals return the request. The recent commit 7dc3c5a0 ("ALSA: usb-audio: Don't create jack controls for PCM terminals") excluded those phantom terminals, so those events are ignored, too. My first thought was that this could be easily deduced from the associated terminals, but some of them have even no associate terminal ID, hence it's not too trivial to figure out. Since the number of such terminals are small and limited, this patch implements another quirk table for the simple mapping of the connectors. It's not really scalable, but let's hope that there will be not many such funky devices in future. Fixes: 7dc3c5a0 ("ALSA: usb-audio: Don't create jack controls for PCM terminals") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206873 Link: https://lore.kernel.org/r/20200422113320.26664-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Jason Yan authored
Fix the following coccicheck warning: sound/pci/oxygen/xonar_pcm179x.c:463:1-17: WARNING: Assignment of 0/1 to bool variable sound/pci/oxygen/xonar_pcm179x.c:505:1-17: WARNING: Assignment of 0/1 to bool variable Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20200422071646.48436-1-yanaijie@huawei.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Dan Carpenter authored
This should be ARRAY_SIZE() instead of sizeof(). The sizeof() limit is too high so it doesn't work. Fixes: 093b8494 ("ALSA: usb-audio: Print more information in stream proc files") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20200422092255.GB195357@mwandaSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 21 Apr, 2020 5 commits
-
-
Takashi Iwai authored
Merge tag 'asoc-fix-v5.7-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.7 Quite a lot of fixes here, a lot of driver specific ones but the biggest one is the revert of changes to the startup and shutdown sequence for DAIs that went in during the merge window - they broke some older x86 platforms and attempts to fix them didn't succeed so it's safer to just roll them back and try to make sure those platforms are handled properly in any future attempt. The rockchip S/PDIF DT stuff was IIRC for validation issues.
-
Alexander Tsoy authored
Due to rounding error driver sometimes incorrectly calculate next packet size, which results in audible clicks on devices with synchronous playback endpoints. For example on a high speed bus and a sample rate 44.1 kHz it loses one sample every ~40.9 seconds. Fortunately playback interface on Scarlett 2i4 2nd gen has a working explicit feedback endpoint, so we can switch playback data endpoint to asynchronous mode as a workaround. Signed-off-by: Alexander Tsoy <alexander@tsoy.me> Link: https://lore.kernel.org/r/20200421190908.462860-1-alexander@tsoy.meSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Shengjiu Wang authored
After suspend & resume, wm8960_hw_params may be called when bias_level is not SND_SOC_BIAS_ON, then wm8960_configure_clocking is not called. But if sample rate is changed at that time, then the output clock rate will be not correct. So judgement of bias_level is SND_SOC_BIAS_ON in wm8960_hw_params is not necessary and it causes above issue. Fixes: 3176bf2d ("ASoC: wm8960: update pll and clock setting function") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/1587468525-27514-1-git-send-email-shengjiu.wang@nxp.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Takashi Iwai authored
The error handling code in usX2Y_rate_set() may hit a potential NULL dereference when an error occurs before allocating all us->urb[]. Add a proper NULL check for fixing the corner case. Reported-by: Lin Yi <teroincn@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200420075529.27203-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Gregor Pintar authored
Force it to use asynchronous playback. Same quirk has already been added for Focusrite Scarlett Solo (2nd gen) with a commit 46f5710f ("ALSA: usb-audio: Add quirk for Focusrite Scarlett Solo"). This also seems to prevent regular clicks when playing at 44100Hz on Scarlett 2i2 (2nd gen). I did not notice any side effects. Moved both quirks to snd_usb_audioformat_attributes_quirk() as suggested. Signed-off-by: Gregor Pintar <grpintar@gmail.com> Reviewed-by: Alexander Tsoy <alexander@tsoy.me> Link: https://lore.kernel.org/r/20200420214030.2361-1-grpintar@gmail.comSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 20 Apr, 2020 9 commits
-
-
YueHaibing authored
sound/soc/codecs/wm8900.o: In function `wm8900_i2c_probe': wm8900.c:(.text+0xa36): undefined reference to `__devm_regmap_init_i2c' sound/soc/codecs/wm8900.o: In function `wm8900_modinit': wm8900.c:(.init.text+0xb): undefined reference to `i2c_register_driver' sound/soc/codecs/wm8900.o: In function `wm8900_exit': wm8900.c:(.exit.text+0x8): undefined reference to `i2c_del_driver' sound/soc/codecs/wm8988.o: In function `wm8988_i2c_probe': wm8988.c:(.text+0x857): undefined reference to `__devm_regmap_init_i2c' sound/soc/codecs/wm8988.o: In function `wm8988_modinit': wm8988.c:(.init.text+0xb): undefined reference to `i2c_register_driver' sound/soc/codecs/wm8988.o: In function `wm8988_exit': wm8988.c:(.exit.text+0x8): undefined reference to `i2c_del_driver' sound/soc/codecs/wm8995.o: In function `wm8995_i2c_probe': wm8995.c:(.text+0x1c4f): undefined reference to `__devm_regmap_init_i2c' sound/soc/codecs/wm8995.o: In function `wm8995_modinit': wm8995.c:(.init.text+0xb): undefined reference to `i2c_register_driver' sound/soc/codecs/wm8995.o: In function `wm8995_exit': wm8995.c:(.exit.text+0x8): undefined reference to `i2c_del_driver' Add SND_SOC_I2C_AND_SPI dependency to fix this. Fixes: ea00d952 ("ASoC: Use imply for SND_SOC_ALL_CODECS") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200420125343.20920-1-yuehaibing@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Mark Brown authored
Merge series "ASoC: rsnd: multi-SSI setup fixes" from Matthias Blankertz <matthias.blankertz@cetitec.com>: Fix rsnd_dai_call() operations being performed twice for the master SSI in multi-SSI setups, and fix the rsnd_ssi_stop operation for multi-SSI setups. The only visible effect of these issues was some "status check failed" spam when the rsnd_ssi_stop was called, but overall the code is cleaner now, and some questionable writes to the SSICR register which did not lead to any observable misbehaviour but were contrary to the datasheet are fixed. Mark: The first patch kind of reverts my "ASoC: rsnd: Fix parent SSI start/stop in multi-SSI mode" from a few days ago and achieves the same effect in a simpler fashion, if you would prefer a clean patch series based on v5.6 drop me a note. Greetings, Matthias Matthias Blankertz (2): ASoC: rsnd: Don't treat master SSI in multi SSI setup as parent ASoC: rsnd: Fix "status check failed" spam for multi-SSI sound/soc/sh/rcar/ssi.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) base-commit: 15a5760c -- 2.26.1
-
Mark Brown authored
Merge series "ASoC: meson: fix codec-to-codec link setup" from Jerome Brunet <jbrunet@baylibre.com>: This patchset fixes the problem reported by Marc in this thread [0] The problem was due to an error in the meson card drivers which had the "no_pcm" dai_link property set on codec-to-codec links [0]: https://lore.kernel.org/r/20200417122732.GC5315@sirena.org.uk Jerome Brunet (2): ASoC: meson: axg-card: fix codec-to-codec link setup ASoC: meson: gx-card: fix codec-to-codec link setup sound/soc/meson/axg-card.c | 4 +++- sound/soc/meson/gx-card.c | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) -- 2.25.2
-
Gyeongtaek Lee authored
snd_soc_dapm_kcontrol widget which is created by autodisable control should contain correct on_val, mask and shift because it is set when the widget is powered and changed value is applied on registers by following code in dapm_seq_run_coalesced(). mask |= w->mask << w->shift; if (w->power) value |= w->on_val << w->shift; else value |= w->off_val << w->shift; Shift on the mask in dapm_kcontrol_data_alloc() is removed to prevent double shift. And, on_val in dapm_kcontrol_set_value() is modified to get correct value in the dapm_seq_run_coalesced(). Signed-off-by: Gyeongtaek Lee <gt82.lee@samsung.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/000001d61537$b212f620$1638e260$@samsung.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Matthias Blankertz authored
Fix the rsnd_ssi_stop function to skip disabling the individual SSIs of a multi-SSI setup, as the actual stop is performed by rsnd_ssiu_stop_gen2 - the same logic as in rsnd_ssi_start. The attempt to disable these SSIs was harmless, but caused a "status check failed" message to be printed for every SSI in the multi-SSI setup. The disabling of interrupts is still performed, as they are enabled for all SSIs in rsnd_ssi_init, but care is taken to not accidentally set the EN bit for an SSI where it was not set by rsnd_ssi_start. Signed-off-by: Matthias Blankertz <matthias.blankertz@cetitec.com> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20200417153017.1744454-3-matthias.blankertz@cetitec.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Matthias Blankertz authored
The master SSI of a multi-SSI setup was attached both to the RSND_MOD_SSI slot and the RSND_MOD_SSIP slot of the rsnd_dai_stream. This is not correct wrt. the meaning of being "parent" in the rest of the SSI code, where it seems to indicate an SSI that provides clock and word sync but is not transmitting/receiving audio data. Not treating the multi-SSI master as parent allows removal of various special cases to the rsnd_ssi_is_parent conditions introduced in commit a09fb3f2 ("ASoC: rsnd: Fix parent SSI start/stop in multi-SSI mode"). It also fixes the issue that operations performed via rsnd_dai_call() were performed twice for the master SSI. This caused some "status check failed" spam when stopping a multi-SSI stream as the driver attempted to stop the master SSI twice. Signed-off-by: Matthias Blankertz <matthias.blankertz@cetitec.com> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20200417153017.1744454-2-matthias.blankertz@cetitec.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Jerome Brunet authored
Since the addition of commit 9b5db059 ("ASoC: soc-pcm: dpcm: Only allow playback/capture if supported"), meson-axg cards which have codec-to-codec links fail to init and Oops. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000128 Internal error: Oops: 96000044 [#1] PREEMPT SMP CPU: 3 PID: 1582 Comm: arecord Not tainted 5.7.0-rc1 pc : invalidate_paths_ep+0x30/0xe0 lr : snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8 Call trace: invalidate_paths_ep+0x30/0xe0 snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8 dpcm_path_get+0x38/0xd0 dpcm_fe_dai_open+0x70/0x920 snd_pcm_open_substream+0x564/0x840 snd_pcm_open+0xfc/0x228 snd_pcm_capture_open+0x4c/0x78 snd_open+0xac/0x1a8 ... While this error was initially reported the axg-card type, it also applies to the gx-card type. While initiliazing the links, ASoC treats the codec-to-codec links of this card type as a DPCM backend. This error eventually leads to the Oops. Most of the card driver code is shared between DPCM backends and codec-to-codec links. The property "no_pcm" marking DCPM BE was left set on codec-to-codec links, leading to this problem. This commit fixes that. Fixes: e37a0c31 ("ASoC: meson: gx: add sound card support") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20200420114511.450560-3-jbrunet@baylibre.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Jerome Brunet authored
Since the addition of commit 9b5db059 ("ASoC: soc-pcm: dpcm: Only allow playback/capture if supported"), meson-axg cards which have codec-to-codec links fail to init and Oops: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000128 Internal error: Oops: 96000044 [#1] PREEMPT SMP CPU: 3 PID: 1582 Comm: arecord Not tainted 5.7.0-rc1 pc : invalidate_paths_ep+0x30/0xe0 lr : snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8 Call trace: invalidate_paths_ep+0x30/0xe0 snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8 dpcm_path_get+0x38/0xd0 dpcm_fe_dai_open+0x70/0x920 snd_pcm_open_substream+0x564/0x840 snd_pcm_open+0xfc/0x228 snd_pcm_capture_open+0x4c/0x78 snd_open+0xac/0x1a8 ... While initiliazing the links, ASoC treats the codec-to-codec links of this card type as a DPCM backend. This error eventually leads to the Oops. Most of the card driver code is shared between DPCM backends and codec-to-codec links. The property "no_pcm" marking DCPM BE was left set on codec-to-codec links, leading to this problem. This commit fixes that. Fixes: 0a8f1117 ("ASoC: meson: axg-card: add basic codec-to-codec link support") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20200420114511.450560-2-jbrunet@baylibre.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Takashi Iwai authored
TRX40 mobos from MSI and others with ALC1220-VB USB-audio device need yet more quirks for the proper control names. This patch provides the mapping table for those boards, correcting the FU names for volume and mute controls as well as the terminal names for jack controls. It also improves build_connector_control() not to add the directional suffix blindly if the string is given from the mapping table. With this patch applied, the new UCM profiles will be effective. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206873 Link: https://lore.kernel.org/r/20200420062036.28567-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
- 19 Apr, 2020 2 commits
-
-
Takashi Iwai authored
For more debug and usability information, add the entry showing the DSD raw states and the channel mapping in each stream proc file. Link: https://lore.kernel.org/r/20200419212134.14200-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>
-
Linus Torvalds authored
-