When the usb-audio descriptor contains the malformed feature unit
description with a too short length, the driver may access
out-of-bounds. Add a sanity check of the header size at the beginning
of parse_audio_feature_unit().
Fixes: 23caaf19b1 ("ALSA: usb-mixer: Add support for Audio Class v2.0")
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some timer compat ioctls have NULL checks of timer instance with
snd_BUG_ON() that bring up WARN_ON() when the debug option is set.
Actually the condition can be met in the normal situation and it's
confusing and bad to spew kernel warnings with stack trace there.
Let's remove snd_BUG_ON() invocation and replace with the simple
checks. Also, correct the error code to EBADFD to follow the native
ioctl error handling.
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
commit 3179f62001 ("ALSA: core: add .get_time_info") had a side effect
of changing the behaviour of the PCM runtime tstamp. Prior to this
change tstamp was not updated by snd_pcm_update_hw_ptr0() unless the
hw_ptr had moved, after this change tstamp was always updated.
For an application using alsa-lib, doing snd_pcm_readi() followed by
snd_pcm_status() to estimate the age of the read samples by subtracting
status->avail * [sample rate] from status->tstamp this change degraded
the accuracy of the estimate on devices where the pcm hw does not
provide a granular hw_ptr, e.g., devices using
soc-generic-dmaengine-pcm.c and a dma-engine with residue_granularity
DMA_RESIDUE_GRANULARITY_DESCRIPTOR. The accuracy of the estimate
depended on the latency between the PCM hw completing a period and the
driver called snd_pcm_period_elapsed() to notify ALSA core, typically
determined by interrupt handling latency. After the change the accuracy
of the estimate depended on the latency between the PCM hw completing a
period and the application calling snd_pcm_status(), determined by the
scheduling of the application process. The maximum error of the
estimate is one period length in both cases, but the error average and
variance is smaller when it depends on interrupt latency.
Instead of always updating tstamp, update it only if audio_tstamp
changed.
Fixes: 3179f62001 ("ALSA: core: add .get_time_info")
Suggested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Henrik Eriksson <henrik.eriksson@axis.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Users have been using knob "model=dell-headset-multi" on Intel Skull
Canyon for a while.
Add the equivalent quirk, ALC269_FIXUP_DELL1_MIC_NO_PRESENCE for Skull
Canyon.
BugLink: https://bugs.launchpad.net/bugs/1732034
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We got a regression report about the HD-audio HDMI chmap, where some
surround channels are reported as UNKNOWN. The git bisection pointed
the culprit at the commit 9b3dc8aa3f ("ALSA: hda - Register chmap
obj as priv data instead of codec"). The story behind scene is like
this:
- While moving the code out of the legacy HDA to the HDA common place,
the patch modifies the code to obtain the chmap array indirectly in
a byte array, and it expands it to kctl value array.
- At the latter operation, the size of the array is wrongly passed by
sizeof() to the pointer.
- It can be 4 on 32bit arch, thus too short for 6+ channels.
(And that's the reason why it didn't hit other persons; it's 8 on
64bit arch, thus it's usually enough.)
The code was further changed meanwhile, but the problem persisted.
Let's fix it by correctly evaluating the array size.
Fixes: 9b3dc8aa3f ("ALSA: hda - Register chmap obj as priv data instead of codec")
Reported-by: VDR User <user.vdr@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When an interrupt occurs, the value of at least one of the belonging
controls should have changed. To make sure they get re-read from device
on the next read, invalidate the cache. This was correctly implemented
for uac2 already, but missing for uac1.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Sound works after a cold boot but not after a reboot from windows.
This patch will solve this issue. This is relation with Class-D power control.
[ The bug was reported in Bugzilla below for Sony VAIO SVS13A1C5E
-- tiwai]
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197737
Cc: <stable@vger.kernel.org>
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Symbol SND_SOC_INTEL_SST_TOPLEVEL is user selectable so add the
help text for this symbol.
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The biggest thing this release has been the conversion of the AC98 bus
to the driver model, that's been a long time coming so thanks to Robert
Jarzmik for his dedication there. Due to there being some AC97 MFD
there's a few fairly large changes in input and the MFD layer, mainly to
the wm97xx driver.
There's also some drivers/drm changes to support the new AMD Stoney
platform, these are shared with the DRM subsystem and should be being
merged via both.
Within the subsystem the overwhelming bulk of the changes is in the
Intel drivers which continue to need lots of cleanups and fixes, this
release they've also gained support for their open source firmware.
There's also some large changs in the core as Morimoto-san continues to
mirror operations into the component level in preparation for conversion
of drivers to that.
- The AC97 bus has finally caught up with the driver model thanks to
some dedicated and persistent work from Robert Jarzmik.
- Continued work from Morimoto-san on moving us towards being able to
use components for everything.
- Lots of cleanups for the Intel platform code, including support for
their open source audio firmware.
- Support for scaling MCLK with sample rate in simple-card.
- Support for AMD Stoney platform.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAloJhwMTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0KzbB/9tXryXYz3dnKVlm9rk+Cq0Xy4TrUNk
WY+Il+Di1b6CQJbAm9GSacJxR+siupZCjGC5roHznj/AA2l0RuxJXpxG40Db8ZX+
bDR7mIWtuTUJHazqXltafj9ydElRKVpOGPAi5YJhhW5bXQ3SR9fFy0D3mdcT02v4
SyMExhOMz+mdnuBhbWx9kqJ9LPzCs0ow+R4uoRgAQxpFXPBGtq06sMkK86lGfsl/
iRM36J6FIeIQQfSHG/dkkpoybVax43z4OH7G1IL2FOU7miwkjZh/TTh/xHTd86Mc
OOuGu4hB+MjvccSOa9HSrOqFjxtkZipstwqYVWoYQcUoIVpcg0YRk7TG
=5KBY
-----END PGP SIGNATURE-----
Merge tag 'asoc-v4.15' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Updates for v4.15
The biggest thing this release has been the conversion of the AC98 bus
to the driver model, that's been a long time coming so thanks to Robert
Jarzmik for his dedication there. Due to there being some AC97 MFD
there's a few fairly large changes in input and the MFD layer, mainly to
the wm97xx driver.
There's also some drivers/drm changes to support the new AMD Stoney
platform, these are shared with the DRM subsystem and should be being
merged via both.
Within the subsystem the overwhelming bulk of the changes is in the
Intel drivers which continue to need lots of cleanups and fixes, this
release they've also gained support for their open source firmware.
There's also some large changs in the core as Morimoto-san continues to
mirror operations into the component level in preparation for conversion
of drivers to that.
- The AC97 bus has finally caught up with the driver model thanks to
some dedicated and persistent work from Robert Jarzmik.
- Continued work from Morimoto-san on moving us towards being able to
use components for everything.
- Lots of cleanups for the Intel platform code, including support for
their open source audio firmware.
- Support for scaling MCLK with sample rate in simple-card.
- Support for AMD Stoney platform.
I've been quite lax in sending these due to conference season but here's
a fairly large collection of ASoC updates. The one thing that's not
device specific is Takashi's fix for races between delayed work and PCM
destruction, otherwise everything is specific to an individual device.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlnx7QsTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0H6gB/9Kg6nfaNQDH3ScDO/0KXJevvc9DZUG
1Mgb6o866WQKVKwHL4/7PeUnwpaAh/Dr5KN7bFS7nImrZlHiJfv64Cmrrca+VMwa
O9SnAxbzMDN1MXV3uLDlmd5jJ2EETGnSSo31gjyOuFAmvWRYhtvN4QtoLRBQYYJ9
A32JAKYXKpdjYlIq8sssf1Ey9OcReho3klAc578Yw5qsuHTsB8yJ5SNy0YgmobCm
rNs+LcY9fBPQxY1nVW5iJ3L8oR9RXlUOdZy1I220i0q6+ku1nynbh64V8m7fFGmp
KQLIVvH8JGlqaGBidU47C3vwEnUN88y0+98i9dF4Hc26E+Ml3YNyL/z6
=TVgt
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAloGGn8THGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0BAsB/9tbgkbKpUVsWEQOTXDtz1VARb5+zxJ
zMRmYGdcfV+au4pmo07NwcxwFDqeLxmsd7dRM+eoPJGbxklD9rr9eL9tZiO1TI0B
jla9eyKO1aRjCD8dEDsQJEUjDGWWbrpYRvFjlTmYW5cf1vgE9Ta7QtwBN+mK+Ssn
1PtwfHg5lDffoCMGOgu/5Kah4QhzAIU1mM4Vg77VgsuScZEw5qMYJUncfkdsH6M5
JiQJpOQR/wNL4/IETodjhFzqhi9vlUvDEfmATNMpHMdHA//erUbphUt2bAjqVauM
zKTFTSN1vvW1GirJyxz4NiHXQ6upbpZPMDcPsfOzJhHw82OAwx/pp1QT
=bBtM
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v4.14-rc6' into asoc-linus
ASoC: Fixes for v4.14
I've been quite lax in sending these due to conference season but here's
a fairly large collection of ASoC updates. The one thing that's not
device specific is Takashi's fix for races between delayed work and PCM
destruction, otherwise everything is specific to an individual device.
# gpg: Signature made Thu 26 Oct 2017 15:11:23 BST
# gpg: using RSA key ADE668AA675718B59FE29FEA24D68B725D5487D0
# gpg: issuer "broonie@kernel.org"
# gpg: Good signature from "Mark Brown <broonie@sirena.org.uk>" [unknown]
# gpg: aka "Mark Brown <broonie@debian.org>" [unknown]
# gpg: aka "Mark Brown <broonie@kernel.org>" [unknown]
# gpg: aka "Mark Brown <broonie@tardis.ed.ac.uk>" [unknown]
# gpg: aka "Mark Brown <broonie@linaro.org>" [unknown]
# gpg: aka "Mark Brown <Mark.Brown@linaro.org>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 3F25 68AA C269 98F9 E813 A1C5 C3F4 36CA 30F5 D8EB
# Subkey fingerprint: ADE6 68AA 6757 18B5 9FE2 9FEA 24D6 8B72 5D54 87D0
DSP modes and left/right justified modes can be supported
on bcm2835 by configuring the frame sync polarity and
frame sync length registers and by adjusting the
channel data position registers.
Clock and frame sync polarity handling in hw_params has
been refactored to make the interaction between logical
rising/falling edge frame start and physical configuration
(changed by normal/inverted polarity modes) clearer.
Modes where the first active data bit is transmitted immediately
after frame start (eg DSP mode B with slot 0 active)
only work reliable if bcm2835 is configured as frame master.
In frame slave mode channel swap (or shift, this isn't quite
clear yet) can occur.
Currently the driver only warns if an unstable configuration
is detected but doensn't prevent using them.
Signed-off-by: Matthias Reichl <hias@horus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
bcm2835's configuration registers can't be changed when a stream
is running, which means asymmetric configurations aren't supported.
Channel and rate symmetry are already enforced by constraints
but samplebits had been missed.
As hw_params doesn't check for symmetry constraints by itself
and just returns success if a stream is running this led to
situations where asymmetric configurations were seeming to
succeed but of course didn't work because the hardware wasn't
configured at all.
Fix this by adding the missing samplerate symmetry constraint.
Signed-off-by: Matthias Reichl <hias@horus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Sample rates are only restricted by the capabilities of the
clock driver, so use SNDRV_PCM_RATE_CONTINUOUS instead of
SNDRV_PCM_RATE_8000_192000.
Tests (eg with pcm5122) have shown that bcm2835 works fine
in 384kHz/32bit stereo mode, so change the maximum allowed
rate from 192kHz to 384kHz.
Signed-off-by: Matthias Reichl <hias@horus.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Mark Brown <broonie@kernel.org>
bcm2835 supports arbitrary positioning of channel data within
a frame and thus is capable of supporting TDM modes. Since
the driver is limited to 2-channel operations only TDM setups
with exactly 2 active slots are supported.
Logical TDM slot numbering follows the usual convention:
For I2S-like modes, with a 50% duty-cycle frame clock,
slots 0, 2, ... are transmitted in the first half of a frame,
slots 1, 3, ... are transmitted in the second half.
For DSP modes slot numbering is ascending: 0, 1, 2, 3, ...
Channel position calculation has been refactored to use
TDM info and moved out of hw_params.
set_tdm_slot, set_bclk_ratio and hw_params now check more
strictly if the configuration is valid. Illegal configurations
like odd number of slots in I2S mode, data lengths exceeding
slot width or frame sizes larger than the hardware limit of
1024 are rejected. Also hw_params now properly checks for
errors from clk_set_rate.
Allowed PCM formats are already guarded by stream constraints,
thus the formats check in hw_params has been removed and
data_length is now retrieved via params_width().
Also standard functions like snd_soc_params_to_bclk are now
being used instead of manual calculations to make the code
more readable.
Special care has been taken to ensure that set_bclk_ratio works
as before. The bclk ratio is mapped to a 2-channel TDM config
with a slot width of half the ratio. In order to support odd ratios,
which can't be expressed via a TDM config, the ratio (frame length)
is stored and used by hw_params.
Signed-off-by: Matthias Reichl <hias@horus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add mclk-fs support to audio graph card
as it was previously implemented in simple card.
Signed-off-by: Olivier Moysan <olivier.moysan@st.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The main rt5514 driver optionally calls into the SPI back-end to load
the firmware. This causes a link error when one driver selects rt5514
as built-in and another driver selects rt5514-spi as a loadable module:
sound/soc/codecs/rt5514.o: In function `rt5514_dsp_voice_wake_up_put':
rt5514.c:(.text+0xac8): undefined reference to `rt5514_spi_burst_write'
As a workaround, this adds another silent symbol, to force rt5514-spi
to be built-in for that configuration. I'm not overly happy with
that solution, but couldn't come up with anything better. Using
'IS_REACHABLE()' would break the case that relies on the loadable
module, and all other ideas would result in more complexity.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The new functions are only used when CONFIG_PM is enabled,
leading to a harmless warning:
sound/soc/codecs/rt5514-spi.c:474:12: error: 'rt5514_resume' defined but not used [-Werror=unused-function]
sound/soc/codecs/rt5514-spi.c:464:12: error: 'rt5514_suspend' defined but not used [-Werror=unused-function]
This marks them as __maybe_unused to make the build silent
again.
Fixes: 58f1c07d23 ("ASoC: rt5514: Voice wakeup support.")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Check the JD status in the button pushing to prevent the IRQ that is locked
by button pushing event while the jack unpluging.
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Before rendering starts, DMA driver copies full buffer valid data
to ACP SRAM for the first time, after that ACP SRAM to I2S
FIFO DMA will be initiated. After rendering first half of ACP SRAM,
IOC will be raised then Audio data will be copied from first half of
System Memory to first half of ACP SRAM. Similarly after rendering
second half of ACP SRAM, IOC will be raised then Audio Data will be
copied from second half of the System Memory to second half of the
ACP SRAM in ping-pong way till rendering stops.
Old design introducing latency issues resulting stutter sound observed
during playback.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Signed-off-by: Akshu Agrawal <Akshu.Agrawal@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Minimum time required between power On of codec and read
of RT5645_VENDOR_ID2 is 400msec. We should wait that long
before reading the value.
TEST=Cold boot the device and check for sound device.
Signed-off-by: Akshu Agrawal <akshu.agrawal@amd.com>
Signed-off-by: Bard Liao <bardliao@realtek.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
32bit and 24bit audio capture formats for H3/H2+ are broken because the
RX_SAMPLE_BITS and the RX_FIFO_MODE bits of AC_ADC_FIFOC register of the audio
codec are not set to operate in 24bit mode but in 16bit mode only.
The following patch sets the H3 audio codec registers and the DMA bus width
properly when a 24/32bit capture is requested.
Signed-off-by: Andrea Bondavalli <andrea.bondavalli74@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
DSP modes are documented in the data sheet but not enabled in the driver.
The work-around already implemented for DA7218/9 is also required to
make sure the bit clock handling in DSP modes follows ASoC conventions.
Tested with ARD-AUDIO-DA7212 and Minnowmax Turbot boards
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The current code might be a bit intriguing without having experienced the
issue before, and might come up as a mistake.
Make explicit what's going on by adding a comment.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
While the current code was reporting to be able to work in master mode, it
failed to do so because the BCLK divider wasn't programmed, meaning that
the BCLK would run at the PLL's frequency no matter the sample rate.
It was obviously a bit too fast.
Add support to retrieve the divider to use, and set it. Since our PLL is
not always able to generate a perfect multiple of the sample rate, we'll
have to choose the closest divider that matches our setup.
Fixes: 36c684936f ("ASoC: Add sun8i digital audio codec")
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
In the probe, the codec may not be ready for I2C reading or there are some
glitches on the i2c line. So if the i2c reading value is incorrect, it will
read again after delay. This issue is similar the patch
https://patchwork.kernel.org/patch/9681421/. In current project, these 2
devices were connected to the same i2c line, and they met the same problem.
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Confirmed with Kailang of Realtek, the pin 0x19 is for Headset Mic, and
the pin 0x1a is for Headphone Mic, he suggested to apply
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE to fix this problem. And we
verified applying this FIXUP can fix this problem.
Cc: <stable@vger.kernel.org>
Cc: Kailang Yang <kailang@realtek.com>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ERROR: "__aeabi_uldivmod" [sound/soc/amd/snd-soc-acp-pcm.ko] undefined!
64-bit divides require special operations to avoid build errors on 32-bit
systems.
[Reword the commit message to make it clearer - Alex]
fixes: 61add81479 (ASoC: amd: Report accurate hw_ptr during dma)
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/678919
Reviewed-by: Jason Clinton <jclinton@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/681618
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
For wake on voice use case, we need to copy data from DSP buffer
to PCM stream when system wakes up by voice. However the edge
triggered IRQ could be missed when system wakes up, in that case
the irq function will not be called. If the substream was constructed
beforce suspend, we will schedule data copy in resume function.
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Takashi Iwai
Henrik Eriksson
Kai-Heng Feng
Julian Scheel
Kailang Yang
Vinod Koul
Mark Brown
Matthias Reichl
Olivier Moysan
Arnd Bergmann
oder_chiou@realtek.com
Vijendar Mukunda
Akshu Agrawal
Andrea Bondavalli
Pierre-Louis Bossart
Maxime Ripard
Hui Wang
Guenter Roeck