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.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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@mwanda
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: 87dc36482c ("ALSA: hda/realtek - Add LED class support for micmute LED")
Link: https://lore.kernel.org/r/20200501072857.13720-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: 8fdff6a319 ("ALSA: snd-usb: implement new endpoint streaming model")
Link: https://lore.kernel.org/r/20200424074016.14301-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The commit 3c6fd1f07e ("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.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: c4c8dd6ef8 ("ALSA: hda: Skip controller resume if not needed")
Link: https://lore.kernel.org/r/20200422203744.26299-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: 447d6275f0 ("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.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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 7dc3c5a017 ("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: 7dc3c5a017 ("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.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This should be ARRAY_SIZE() instead of sizeof(). The sizeof() limit is
too high so it doesn't work.
Fixes: 093b8494f2 ("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@mwanda
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl6fSlITHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0ODsB/4whz1ppFUJ4+XLaLoOTCJjKPnQEg6N
lZRhPS1/gQVL/qUpwOIS3vr3Z+8Zsm9F3VXOEGmMFfPR1f4+Fejz1OJkg0mUuhzr
Xx+LHOGyaabj9zvoNxZDS1eE00t8dLrkoRx6vce3dRZluZ5DATN6L/4EB3RIhuny
4ckuQAf6KEGLYpqzAVAJyUp8Q6pBl15vHyH+KMXHZJ4qxQjZaBPA7tPabdzRqStM
Lq+xKkBkJepDet3vQZvvmwNPhS0pU1aqqcopVxj03zivpMwQRftcSYTpdT2SpIF1
GM1FGiRV1lbNUsQNnhkImE9V6X+I3zmQR4dLUbGTT+Le/0e8CtKRXYCQ
=D8Su
-----END PGP SIGNATURE-----
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.
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.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: 3176bf2d7c ("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.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Force it to use asynchronous playback.
Same quirk has already been added for Focusrite Scarlett Solo (2nd gen)
with a commit 46f5710f0b ("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.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: ea00d95200 ("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.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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: 15a5760cb8
--
2.26.1
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
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.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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
a09fb3f28a ("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.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the addition of commit 9b5db05936 ("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: e37a0c313a ("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.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the addition of commit 9b5db05936 ("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: 0a8f1117a6 ("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.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The commit 3c6fd1f07e ("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.
This patch reverts the corresponding entry as a temporary solution.
Although Zenith II and co will see get the empty HD-audio bus again,
it'd be merely resource wastes and won't affect the functionality,
so it's no end of the world. We'll need to address this later,
e.g. by either switching to DMI string matching or using PCI ID &
SSID pairs.
Fixes: 3c6fd1f07e ("ALSA: hda: Add driver blacklist")
Reported-by: Johnathan Smithinovic <johnathan.smithinovic@gmx.at>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200419071926.22683-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The commit 1c76aa5fb4 ("ALSA: hda/realtek - Allow skipping
spec->init_amp detection") changed the way to assign spec->init_amp
field that specifies the way to initialize the amp. Along with the
change, the commit also replaced a few fixups that set spec->init_amp
in HDA_FIXUP_ACT_PROBE with HDA_FIXUP_ACT_PRE_PROBE. This was rather
aligning to the other fixups, and not supposed to change the actual
behavior.
However, this change turned out to cause a regression on FSC S7020,
which hit exactly the above. The reason was that there is still one
place that overrides spec->init_amp after HDA_FIXUP_ACT_PRE_PROBE
call, namely in alc_ssid_check().
This patch fixes the regression by adding the proper spec->init_amp
override check, i.e. verifying whether it's still ALC_INIT_UNDEFINED.
Fixes: 1c76aa5fb4 ("ALSA: hda/realtek - Allow skipping spec->init_amp detection")
Cc: <stable@vger.kernel.org>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207329
Link: https://lore.kernel.org/r/20200418190639.10082-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Many Focusrite devices supports a limited set of sample rates per
altsetting. These includes audio interfaces with ADAT ports:
- Scarlett 18i6, 18i8 1st gen, 18i20 1st gen;
- Scarlett 18i8 2nd gen, 18i20 2nd gen;
- Scarlett 18i8 3rd gen, 18i20 3rd gen;
- Clarett 2Pre USB, 4Pre USB, 8Pre USB.
Maximum rate is exposed in the last 4 bytes of Format Type descriptor
which has a non-standard bLength = 10.
Tested-by: Alexey Skobkin <skobkin-ru@ya.ru>
Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200418175815.12211-1-alexander@tsoy.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Major regressions were detected by SOF CI on CherryTrail and Broadwell:
[ 25.705750] SSP2-Codec: ASoC: no backend playback stream
[ 27.923378] SSP2-Codec: ASoC: no users playback at close - state
This is root-caused to the introduction of the DAI capability checks
with snd_soc_dai_stream_valid(). Its use in soc-pcm.c makes it a
requirement for all DAIs to report at least a non-zero min_channels
field.
For some reason the SSP structures used for SKL+ did provide this
information but legacy platforms didn't.
Fixes: 9b5db05936 ("ASoC: soc-pcm: dpcm: Only allow playback/capture if supported")
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200417172014.11760-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
One significant regression fix is for HD-audio buffer preallocation.
In 5.6 it was set to non-prompt for x86 and forced to 0, but this
turned out to be problematic for some applications, hence it gets
reverted. Distros would need to restore CONFIG_SND_HDA_PREALLOC_SIZE
value to the earlier values they've used in the past.
Other than that, we've received quite a few small fixes for HD-audio
and USB-audio. Most of them are for dealing with the broken TRX40
mobos and the runtime PM without HD-audio codecs.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAl6ZgMEOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE9xIg//W0CkSxsl3yp71o+8Gv+xEWSuOGZ6Gbu5q82e
PXDODxiAUTvzaueQm+ufofQRYxepZfilLweyxyETT2beQeC20Ty+p+S4bEw1uA4Q
NiCkGjJZ6EGxVIb3F1S6n2BMrRckRBFD2xoz6NTd9S/iwAv9dBkUFUit9WywjgOF
XLj0UiTfydgJJ8JIeql6S0glu7Hr+itMcvb3zhIKhvSv0gjR2EFxM6vvl7X9sn8l
b/RYwJmR0ixKSXSTYWOAyJxLETEwRDOVbkyxOMFwU7y/JaE3j6D8xEd7vnT96AmJ
7k9upgh5nRWMGEjIa4lp3ob7HhuMF9q99b2yUG6NsDvP3SffusM8MoDWJ04ULMle
V2sJQQeMk20SuKlNBQfkui9lTbTG1iLRfIjPmJPUHrQNmo4v2P74iQy/7WuJwunK
U1j0A6VJDkQmRp5WNk9tbkwcGLD7x0ZMfnA/fmulT50iU98Qc1ONfbmxDnOMekOC
5AckG3upHS6dlQS61LIK9QENkc1GGQRk7b2eKd7wihYLaQEcvq+6z9ywZiSelhSA
2hc3dAX7RaGR+f2VdWni6uuE+j/XhFblKHWkLlfvY9ESBJgX5s7qys7ogO8+mOfc
8fGyrYFz/bc3Z8ZHqkOPxhfaIHJYyPNR0AXTLCW5di/OZRXBjW6N7rhCHOM7K2YH
uulsJDM=
=2Ir9
-----END PGP SIGNATURE-----
Merge tag 'sound-5.7-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"One significant regression fix is for HD-audio buffer preallocation.
In 5.6 it was set to non-prompt for x86 and forced to 0, but this
turned out to be problematic for some applications, hence it gets
reverted. Distros would need to restore CONFIG_SND_HDA_PREALLOC_SIZE
value to the earlier values they've used in the past.
Other than that, we've received quite a few small fixes for HD-audio
and USB-audio. Most of them are for dealing with the broken TRX40
mobos and the runtime PM without HD-audio codecs"
* tag 'sound-5.7-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda: call runtime_allow() for all hda controllers
ALSA: hda: Allow setting preallocation again for x86
ALSA: hda: Explicitly permit using autosuspend if runtime PM is supported
ALSA: hda: Skip controller resume if not needed
ALSA: hda: Keep the controller initialization even if no codecs found
ALSA: hda: Release resources at error in delayed probe
ALSA: hda: Honor PM disablement in PM freeze and thaw_noirq ops
ALSA: hda: Don't release card at firmware loading error
ALSA: usb-audio: Check mapping at creating connector controls, too
ALSA: usb-audio: Don't create jack controls for PCM terminals
ALSA: usb-audio: Don't override ignore_ctl_error value from the map
ALSA: usb-audio: Filter error from connector kctl ops, too
ALSA: hda/realtek - Enable the headset mic on Asus FX505DT
ALSA: ctxfi: Remove unnecessary cast in kfree
This fixes two issues in the snd-soc-rcar driver blocking multichannel
HDMI audio out: The parent SSI in a multi-SSI configuration is not
correctly set up and started, and the SSI->HDMI channel mapping is
wrong.
With these patches, the following device tree snippet can be used on an
r8a7795-based platform (Salvator-X) to enable multichannel HDMI audio on
HDMI0:
rsnd_port1: port@1 {
rsnd_endpoint1: endpoint {
remote-endpoint = <&dw_hdmi0_snd_in>;
dai-format = "i2s";
bitclock-master = <&rsnd_endpoint1>;
frame-master = <&rsnd_endpoint1>;
playback = <&ssi0 &ssi1 &ssi2 &ssi9>;
};
};
With a capable receiver attached, all of 2ch (stereo), 6ch (e.g. 5.1)
and 8ch audio output should work.
Matthias Blankertz (2):
ASoC: rsnd: Fix parent SSI start/stop in multi-SSI mode
ASoC: rsnd: Fix HDMI channel mapping for multi-SSI mode
sound/soc/sh/rcar/ssi.c | 8 ++++----
sound/soc/sh/rcar/ssiu.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
base-commit: 7111951b8d
--
2.26.0
If we don't find any pcm, pcm will point at address at an offset from
the the list head and not a meaningful structure. Fix this by returning
correct pcm if found and NULL if not. Found with coccinelle.
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/20200415162849.308-1-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The HDMI?_SEL register maps up to four stereo SSI data lanes onto the
sdata[0..3] inputs of the HDMI output block. The upper half of the
register contains four blocks of 4 bits, with the most significant
controlling the sdata3 line and the least significant the sdata0 line.
The shift calculation has an off-by-one error, causing the parent SSI to
be mapped to sdata3, the first multi-SSI child to sdata0 and so forth.
As the parent SSI transmits the stereo L/R channels, and the HDMI core
expects it on the sdata0 line, this causes no audio to be output when
playing stereo audio on a multichannel capable HDMI out, and
multichannel audio has permutated channels.
Fix the shift calculation to map the parent SSI to sdata0, the first
child to sdata1 etc.
Signed-off-by: Matthias Blankertz <matthias.blankertz@cetitec.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/20200415141017.384017-3-matthias.blankertz@cetitec.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The parent SSI of a multi-SSI setup must be fully setup, started and
stopped since it is also part of the playback/capture setup. So only
skip the SSI (as per commit 203cdf51f2 ("ASoC: rsnd: SSI parent cares
SWSP bit") and commit 597b046f0d ("ASoC: rsnd: control SSICR::EN
correctly")) if the SSI is parent outside of a multi-SSI setup.
Signed-off-by: Matthias Blankertz <matthias.blankertz@cetitec.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/20200415141017.384017-2-matthias.blankertz@cetitec.com
Signed-off-by: Mark Brown <broonie@kernel.org>
