The Audioengine D1 (0x2912:0x30c8) does support reading the sample rate,
but it returns the rate in byte-reversed order.
When setting sampling rate, the driver produces these warning messages:
[168840.944226] usb 3-2.2: current rate 4500480 is different from the runtime rate 44100
[168854.930414] usb 3-2.2: current rate 8436480 is different from the runtime rate 48000
[168905.185825] usb 3-2.1.2: current rate 30465 is different from the runtime rate 96000
As can be seen from the hexadecimal conversion, the current rate read
back is byte-reversed from the rate that was set.
44100 == 0x00ac44, 4500480 == 0x44ac00
48000 == 0x00bb80, 8436480 == 0x80bb00
96000 == 0x017700, 30465 == 0x007701
Rather than implementing a new quirk to reverse the order, just skip
checking the rate to avoid spamming the log.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200211162235.1639889-1-nivedita@alum.mit.edu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We've got a regression report about M-Audio Fast Track C400 device,
and the git bisection resulted in the commit e0ccdef926 ("ALSA:
usb-audio: Clean up check_input_term()"). This commit was about the
rewrite of the input terminal parser, and it's not too obvious from
the change what really broke. The answer is: it's the interpretation
of UAC2/3 effect units.
In the original code, UAC2 effect unit is as if through UAC1
processing unit because both UAC1 PU and UAC2/3 EU share the same
number (0x07). The old code went through a complex switch-case
fallthrough, finally bailing out in the middle:
if (protocol == UAC_VERSION_2 &&
hdr[2] == UAC2_EFFECT_UNIT) {
/* UAC2/UAC1 unit IDs overlap here in an
* uncompatible way. Ignore this unit for now.
*/
return 0;
}
... and this special handling was missing in the new code; the new
code treats UAC2/3 effect unit as if it were equivalent with the
processing unit.
Actually, the old code was too confusing. The effect unit has an
incompatible unit description with the processing unit, so we
shouldn't have dealt with EU in the same way.
This patch addresses the regression by changing the effect unit
handling to the own parser function. The own parser function makes
the clear distinct with PU, so it improves the readability, too.
The EU parser just sets the type and the id like the old kernels.
Once when the proper effect unit support is added, we can revisit this
parser function, but for now, let's keep this simple setup as is.
Fixes: e0ccdef926 ("ALSA: usb-audio: Clean up check_input_term()")
Cc: <stable@vger.kernel.org>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206147
Link: https://lore.kernel.org/r/20200211160521.31990-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Jabra Evolve 65 headset appears as if supporting lower rates than
48kHz, but it actually doesn't work but with 48kHz for playback.
This patch applies a workaround to enforce the 48kHz like LINE6
devices already did. The workaround is put in a unified helper
function, set_fixed_rate(), to be called from both places now.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206149
Link: https://lore.kernel.org/r/20200211111419.5895-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
To be compliant with i915 display driver requirements, i915 power-up
must be done before any HDA communication takes place, including
parsing the bus capabilities. Otherwise the initial codec probe
may fail.
Move i915 initialization earlier in the SOF HDA sequence. This
sequence is now aligned with the snd-hda-intel driver where the
display_power() call is before snd_hdac_bus_parse_capabilities()
and rest of the capability parsing.
Also remove unnecessary ifdef around hda_codec_i915_init(). There's
a dummy implementation provided if CONFIG_SND_SOC_SOF_HDA is not
enabled.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200206200223.7715-3-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When HDA controller is resumed from suspend, i915 HDMI/DP
codec requires that following order of actions is kept:
- i915 display power up and configuration of link params
- hda link reset and setup
Current SOF HDA code delegates display codec power control
to the codec driver. This works most of the time, but in
runtime PM sequences, the above constraint may be violated.
On platforms where BIOS values for HDA link parameters do
not match hardware reset defaults, this may lead to errors
in HDA verb transactions after resume.
Fix the issue by explicitly powering the display codec
in the HDA controller resume/suspend calls, thus ensuring
correct ordering. Special handling is needed for the D0i3
flow, where display power must be turned off even though
DSP is left powered.
Now that we have more invocations of the display power helper
functions, the conditional checks surrounding each call have
been moved inside hda_codec_i915_display_power(). The two
special cases of display powering at initial probe are handled
separately. The intent is to avoid powering the display whenever
no display codecs are used.
Note that early powering of display was removed in
commit 687ae9e287 ("ASoC: intel: skl: Fix display power regression").
This change was also copied to the SOF driver. No failures
have resulted as hardware default values for link parameters
have worked out of the box. However with recent i915 driver
changes like done in commit 87c1694533 ("drm/i915: save
AUD_FREQ_CNTRL state at audio domain suspend"), this does not
hold anymore and errors are hit.
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200206200223.7715-2-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
snd_hdac_ext_bus_link_get() does not work correctly in case
there are multiple codecs on the bus. It unconditionally
resets the bus->codec_mask value. As per documentation in
hdaudio.h and existing use in client code, this field should
be used to store bit flag of detected codecs on the bus.
By overwriting value of the codec_mask, information on all
detected codecs is lost. No current user of hdac is impacted,
but use of bus->codec_mask is planned in future patches
for SOF.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200206200223.7715-1-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The ssc audio driver can call into both pdc and dma backends. With the
latest rework, the logic to do this in a safe way avoiding link errors
was removed, bringing back link errors that were fixed long ago in commit
061981ff8c ("ASoC: atmel: properly select dma driver state") such as
sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_set_audio':
atmel_ssc_dai.c:(.text+0xac): undefined reference to `atmel_pcm_pdc_platform_register'
Fix it this time using Makefile hacks and a comment to prevent this
from accidentally getting removed again rather than Kconfig hacks.
Fixes: 1829141055 ("ASoC: atmel: enable SOC_SSC_PDC and SOC_SSC_DMA in Kconfig")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Link: https://lore.kernel.org/r/20200130130545.31148-1-codrin.ciubotariu@microchip.com
Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Mark Brown <broonie@kernel.org>
If the imx-sdma driver is built as a module, the fsl-sai device doesn't
disable on probing failure, which causes the warning in the next probing:
==================================================================
fsl-sai 308a0000.sai: Unbalanced pm_runtime_enable!
fsl-sai 308a0000.sai: Unbalanced pm_runtime_enable!
fsl-sai 308a0000.sai: Unbalanced pm_runtime_enable!
fsl-sai 308a0000.sai: Unbalanced pm_runtime_enable!
fsl-sai 308a0000.sai: Unbalanced pm_runtime_enable!
fsl-sai 308a0000.sai: Unbalanced pm_runtime_enable!
==================================================================
Disabling the device properly fixes the issue.
Fixes: 812ad463e0 ("ASoC: fsl_sai: Add support for runtime pm")
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
Link: https://lore.kernel.org/r/20200205160436.3813642-1-oleksandr.suvorov@toradex.com
Signed-off-by: Mark Brown <broonie@kernel.org>
A collection of pending small fixes since the previous PR.
ALSA core:
- PCM memory leak fix
ASoC:
- Lots of SOF and Intel driver fixes
- Addition of COMMON_CLK for wcd934x
- Regression fixes for AMD and Tegra platforms
HD-audio:
- DP-MST HDMI regression fix, Tegra workarounds, HP quirk fix
Others:
- A few fixes relevant with the recent uapi-updates
- Sparse warnings and endianness fixes
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAl47+oEOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE+GYg//dNu8r2M6y60btHjaWxblmdhHF3XQ5EwSxvSX
QT1gm3pg8PMefJNOSD5IhD7Spll6SYz89YpKpPr3NneV5bcDSozdAt50vbtZvqry
notOqSpL4DubIcYIrhLWI6mq9cIOXIgGnY1cs2KIkoDdNUSDD44nCG1FoUu163tI
mBPDgjZqAAMseCu4jwRInfE2iUJHGNrkQBDc3+1yZFPog/APoLocRKF7paF1N73f
A8kGDCoWUmk8mGb93lUxiDg09gK0aCHNmcjIR4Q4MPD16Yg+o1RgGwY81xdyKjs1
neNCfSCyhYgkON8rvJIsE46qGbqax6/JT7QxCqbyy/Vj4s5MfUivqnWRFwnUisB+
OoQa37Vd893gjxz1+JvmjrqKTWPmSbHMiuqFj5e1X+HqEVxdKDJMMPwzqlVjRq4K
Ma18ACK1EQmb4Hsh2U488EjZp/n/FoOmqFSjE6qaHpfdq7YT0bv2lV+f8QFNmliF
aeJ+ktp6GU2FFV2U4/iZmRUeTZgJpz6m2mLix++Jn11RbSewxj4uyZPKbBYPj7JZ
NK2l/OgMUxj4qM3ZkgQUOnihIWSqdx0lySgXPWe7fLokMTPNsVr5X2ztD9m1uyX8
lbJuZsXNGMUS6v3aAy8zoCp2sc1G8heM5Z/WUiZQtUtjpUJ3DATK7sEdv3hLJpFB
sYw41vs=
=Mcey
-----END PGP SIGNATURE-----
Merge tag 'sound-fix-5.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A collection of pending small fixes:
ALSA core:
- PCM memory leak fix
ASoC:
- Lots of SOF and Intel driver fixes
- Addition of COMMON_CLK for wcd934x
- Regression fixes for AMD and Tegra platforms
HD-audio:
- DP-MST HDMI regression fix, Tegra workarounds, HP quirk fix
Others:
- A few fixes relevant with the recent uapi-updates
- Sparse warnings and endianness fixes"
* tag 'sound-fix-5.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (35 commits)
ALSA: hda: Clear RIRB status before reading WP
ALSA: hda/realtek - Fixed one of HP ALC671 platform Headset Mic supported
ASoC: wcd934x: Add missing COMMON_CLK dependency to SND_SOC_ALL_CODECS
ALSA: hda - Fix DP-MST support for NVIDIA codecs
ASoC: wcd934x: Add missing COMMON_CLK dependency
MAINTAINERS: Remove the Bard Liao from the MAINTAINERS of Realtek CODECs
ASoC: tegra: Revert 24 and 32 bit support
ASoC: SOF: Intel: add PCI ID for JasperLake
ALSA: hdsp: Make the firmware loading ioctl a bit more readable
ALSA: emu10k1: Fix annotation and cast for the recent uapi header change
ALSA: dummy: Fix PCM format loop in proc output
ALSA: usb-audio: Annotate endianess in Scarlett gen2 quirk
ALSA: usb-audio: Fix endianess in descriptor validation
ALSA: hda: Add JasperLake PCI ID and codec vid
ALSA: pcm: Fix sparse warnings wrt snd_pcm_state_t
ALSA: pcm: Fix memory leak at closing a stream without hw_free
ALSA: uapi: Fix sparse warning
ASoC: rt715: Add __maybe_unused to PM callbacks
ASoC: rt711: Add __maybe_unused to PM callbacks
ASoC: rt700: Add __maybe_unused to PM callbacks
...
An incremental fix for the Qualcomm COMMON_CLK issue.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl4776ETHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0JgzB/0WQ36S9WL1/waa5XonLJ+ft9kMKypd
VVVGK70AiAhCWaahYq+BgnuH38Y3oT9G3xm4PnmobDn60t4dN6o+Ga7RlYiDDIa8
TXABNgRlpdn4Dh3xtYtvI1iQ6CifWeltJ3OwLrX9oj7HvaLiua187ovDAthp+jtZ
mkuGlpsiHutpVPapUeDVnv6S+eLzpSmICpw7YV53aewprbBddoFRhNgIOevL71w9
VvlitJAXIwAoto+/r1RExjiUO6fVMuizkGuy5Mg78GK4r0w3AuphQnmD12g9ezdU
oQjin022T2hh23JNkcRPbIHO+oFVpP74rZhz7+jVj23FxweDyU7YrvNw
=b0Bf
-----END PGP SIGNATURE-----
Merge tag 'asoc-v5.6-3' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fix for v5.6
An incremental fix for the Qualcomm COMMON_CLK issue.
RIRB interrupt status getting cleared after the write pointer is read
causes a race condition, where last response(s) into RIRB may remain
unserviced by IRQ, eventually causing azx_rirb_get_response to fall
back to polling mode. Clearing the RIRB interrupt status ahead of
write pointer access ensures that this condition is avoided.
Signed-off-by: Mohan Kumar <mkumard@nvidia.com>
Signed-off-by: Viswanath L <viswanathl@nvidia.com>
Link: https://lore.kernel.org/r/1580983853-351-1-git-send-email-viswanathl@nvidia.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
HP want to keep BIOS verb table for release platform.
So, it need to add 0x19 pin for quirk.
Fixes: 5af29028fd ("ALSA: hda/realtek - Add Headset Mic supported for HP cPC")
Signed-off-by: Kailang Yang <kailang@realtek.com>
Link: https://lore.kernel.org/r/74636ccb700a4cbda24c58a99dc430ce@realtek.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A collection of updates for bugs fixed since the initial pull
request, the most important one being the addition of COMMON_CLK
for wcd934x which is needed for MFD to be merged.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl46jnATHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0FfTB/9pn+BR2PZWE349/Etdj4Tb0mHO3mfG
7sptuPYCXrFRJ82HPcSIIY8nUMBP+lYciIBE4Dn09QDxwPALFuEuzcM7XmJpJIKJ
Vg9ooyYC4/59ijQJXFGR61Xaf30PcvdxE1sC3+SEt6ROn9C/whZHFzpnPJgmeFbq
LIVI2ne/QpPQ+fozvUjkr8nOrEbLIhH6DeCRKExmQ5PYnM7fO//s51HmCUOAxQwJ
FvEH2NCZwvGA43xSYeAdWfE1C3DgdEIT1VKEfeA+Va2tjwPz64mtA6xbaNW99xV6
5/ii/c1x3Yjvy+F6IAqrmwCDZWQJ+xIgy4nbNLd2V8t1alYKWz22aVOr
=qO+a
-----END PGP SIGNATURE-----
Merge tag 'asoc-v5.6-2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v5.6
A collection of updates for bugs fixed since the initial pull
request, the most important one being the addition of COMMON_CLK
for wcd934x which is needed for MFD to be merged.
If dyn_pcm_assign is set, different jack objects are being created
for pcm and pins.
If dyn_pcm_assign is set, generic_hdmi_build_jack() calls into
add_hdmi_jack_kctl() to create and track separate jack object for
pcm. Like sync_eld_via_acomp(), hdmi_present_sense_via_verbs() also
need to report status change of the pcm jack.
Rename pin_idx_to_jack() to pin_idx_to_pcm_jack(). Update
hdmi_present_sense_via_verbs() to report plug state of pcm jack
object. Unlike sync_eld_via_acomp(), for !acomp drivers the pcm
jack's plug state must be consistent with plug state
of pin's jack.
Fixes: 5398e94fb7 ("ALSA: hda - Add DP-MST support for NVIDIA codecs")
Reported-and-tested-by: Martin Regner <martin@larkos.de>
Signed-off-by: Nikhil Mahale <nmahale@nvidia.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200204102746.1356-1-nmahale@nvidia.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Looks like some platforms are not yet using COMMON CLK.
PowerPC allyesconfig failed with below error in next
ld: sound/soc/codecs/wcd934x.o:(.toc+0x0):
undefined reference to `of_clk_src_simple_get'
ld: sound/soc/codecs/wcd934x.o: in function `.wcd934x_codec_probe':
wcd934x.c:(.text.wcd934x_codec_probe+0x3d4):
undefined reference to `.__clk_get_name'
ld: wcd934x.c:(.text.wcd934x_codec_probe+0x438):
undefined reference to `.clk_hw_register'
ld: wcd934x.c:(.text.wcd934x_codec_probe+0x474):
undefined reference to `.of_clk_add_provider'
Add the missing COMMON_CLK dependency to fix this errors.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20200204111241.6927-1-srinivas.kandagatla@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit f3ee99087c ("ASoC: tegra: Allow
24bit and 32bit samples") added 24-bit and 32-bit support for to the
Tegra30 I2S driver. However, there are two additional commits that are
also needed to get 24-bit and 32-bit support to work correctly. These
commits are not yet applied because there are still some review comments
that need to be addressed. With only this change applied, 24-bit and
32-bit support is advertised by the I2S driver, but it does not work and
the audio is distorted. Therefore, revert this patch for now until the
other changes are also ready.
Furthermore, a clock issue with 24-bit support has been identified with
this change and so if we revert this now, we can also fix that in the
updated version.
Reported-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20200131091901.13014-1-jonathanh@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
The firmware loading ioctl that is implemented for hdsp hwdep device
takes the reference of the address pointer, hence the current code is
rather confusing. Also, due to the recent change in uapi header,
sparse also complains about the cast.
This patch tries to improve the readability by converting the
straightforward copy_from_user of the whole struct (which contains
only the pointer).
Fixes: d63e63d421 ("ALSA: hdsp: Make uapi/hdsp.h compilable again")
Link: https://lore.kernel.org/r/20200202090724.18232-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent sound/emu10k1.h uapi header change by the commit
2e46886763 ("ALSA: emu10k1: Make uapi/emu10k1.h compilable again")
made sparse angry because of the inconsistency of __user annotation
and the own ctl id struct that were changed in uapi header.
This patch addresses those by adjusting the cast and annotations
properly again.
Fixes: 2e46886763 ("ALSA: emu10k1: Make uapi/emu10k1.h compilable again")
Link: https://lore.kernel.org/r/20200202090724.18232-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The loop termination for iterating over all formats should contain
SNDRV_PCM_FORMAT_LAST, not less than it.
Fixes: 9b151fec13 ("ALSA: dummy - Add debug proc file")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200201080530.22390-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The Scarlett gen2 mixer quirk code defines a few record types to
communicate via USB hub, and those must be all little-endian.
This patch changes the field types to LE to annotate endianess
properly. It also fixes the incorrect usage of leXX_to_cpu() in a
couple of places, which was caught by sparse after this change.
Fixes: 9e4d5c1be2 ("ALSA: usb-audio: Scarlett Gen 2 mixer interface")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200201080530.22390-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
I overlooked that some fields are words and need the converts from
LE in the recently added USB descriptor validation code.
This patch fixes those with the proper macro usages.
Fixes: 57f8770620 ("ALSA: usb-audio: More validations of descriptor units")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200201080530.22390-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Since we have a bitwise definition of snd_pcm_state_t and use it for
certain struct fields, a few new (and years old) sparse warnings came
up. This patch is an attempt to cover them.
- The state fields in snd_pcm_mmap_status* and co are all defined as
snd_pcm_state_t type now
- The PCM action callbacks take snd_pcm_state_t argument as well;
some actions taking special values got the explicit cast and
comments
- For the PCM action that doesn't need an extra argument receives
ACTION_ARG_IGNORE instead of ambiguous 0
While we're at it, the boolean argument is also properly changed to
bool and true/false, as well as a slight refactoring of PCM pause
helper function to make easier to read.
No functional changes, just shutting up chatty sparse.
Fixes: 46b770f720 ("ALSA: uapi: Fix sparse warning")
Reported-by: kbuild test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20200131152214.11698-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA PCM core recently introduced a new managed PCM buffer allocation
mode that does allocate / free automatically at hw_params and
hw_free. However, it overlooked the code path directly calling
hw_free PCM ops at releasing the PCM substream, and it may result in a
memory leak as spotted by syzkaller when no buffer preallocation is
used (e.g. vmalloc buffer).
This patch papers over it with a slight refactoring. The hw_free ops
call and relevant tasks are unified in a new helper function, and call
it from both places.
Fixes: 0dba808eae ("ALSA: pcm: Introduce managed buffer allocation mode")
Reported-by: syzbot+30edd0f34bfcdc548ac4@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200129195907.12197-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fix the compile warnings by adding __maybe_unused to PM callbacks:
sound/soc/codecs/rt715-sdw.c:566:12: warning: ‘rt715_dev_resume’ defined but not used [-Wunused-function]
sound/soc/codecs/rt715-sdw.c:552:12: warning: ‘rt715_dev_suspend’ defined but not used [-Wunused-function]
Fixes: d1ede0641b ("ASoC: rt715: add RT715 codec driver")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200127192831.14057-5-tiwai@suse.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix the compile warnings by adding __maybe_unused to PM callbacks:
sound/soc/codecs/rt711-sdw.c:504:12: warning: ‘rt711_dev_resume’ defined but not used [-Wunused-function]
sound/soc/codecs/rt711-sdw.c:490:12: warning: ‘rt711_dev_suspend’ defined but not used [-Wunused-function]
Fixes: 320b8b0d13 ("ASoC: rt711: add rt711 codec driver")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200127192831.14057-4-tiwai@suse.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix the compile warnings by adding __maybe_unused to PM callbacks:
sound/soc/codecs/rt700-sdw.c:503:12: warning: ‘rt700_dev_resume’ defined but not used [-Wunused-function]
sound/soc/codecs/rt700-sdw.c:489:12: warning: ‘rt700_dev_suspend’ defined but not used [-Wunused-function]
Fixes: 7d2a5f9ae4 ("ASoC: rt700: add rt700 codec driver")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200127192831.14057-3-tiwai@suse.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix the compile warnings by adding __maybe_unused to PM callbacks:
sound/soc/codecs/rt1308-sdw.c:690:12: warning: ‘rt1308_dev_resume’ defined but not used [-Wunused-function]
sound/soc/codecs/rt1308-sdw.c:676:12: warning: ‘rt1308_dev_suspend’ defined but not used [-Wunused-function]
Fixes: a87a6653a2 ("ASoC: rt1308-sdw: add rt1308 SdW amplifier driver")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200127192831.14057-2-tiwai@suse.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Stopping of one stream is killing the other stream when they
are running simultaneously. This is because, IER register is
cleared which disables I2S and overrides any other block enables.
Clearing IER register only when all streams on a channel are disabled,
fixes the issue.
Signed-off-by: Akshu Agrawal <akshu.agrawal@amd.com>
Link: https://lore.kernel.org/r/20200128103029.128841-1-akshu.agrawal@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
As diffstat shows we've had again a lot of works done for this cycle:
majority of changes are the continued componentization and code
refactoring in ASoC, the tree-wide PCM API updates and cleanups
and SOF updates while a few ASoC driver updates are seen, too.
Here we go, some highlights:
Core:
- Finally y2038 support landed to ALSA ABI;
some ioctls have been extended and lots of tricks were applied
- Applying the new managed PCM buffer API to all drivers;
the API itself was already merged in 5.5
- The already deprecated dimension support in ALSA control API is
dropped completely now
- Verification of ALSA control elements to catch API misuses
ASoC:
- Further code refactorings and moving things to the component level
- Lots of updates and improvements on SOF / Intel drivers;
now including common HDMI driver and SoundWire support
- New driver support for Ingenic JZ4770, Mediatek MT6660, Qualcomm
WCD934x and WSA881x, and Realtek RT700, RT711, RT715, RT1011, RT1015
and RT1308
HD-audio:
- Improved ring-buffer communications using waitqueue
- Drop the superfluous buffer preallocation on x86
Others:
- Many code cleanups, mostly constifications over the whole tree
- USB-audio: quirks for MOTU, Corsair Virtuoso, Line6 Helix
- FireWire: code refactoring for oxfw and dice drivers
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAl4v7qsOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE9s7hAAoeqwRF+WffBaSMZKShDyFD5L7Z/YeXxh2b81
ErnVaSbXmWMhzgx7G7dj3bchkJWYsqAH//j3/AHYCF22slJdeTof0cpqaRgC0qEv
eIj9ALu2Hh+z5jJHOlbpcYevtK89frY9zu4Su/5YAfZloUNLqAbl59SNOiS99/hu
SR5rF0UCGngHf+pjiBpruQv2hahD5Y0a4rIGMaZB/GAa3p7eQ42koMmIEje/rjF0
bSpiYmmAwGJ62RlTUFCBNlj9w78eUfqrf8SHr91d7zNHUZpHR9GoFswmLGM0UtGS
5gIm+6UkBmTQcqgKhYsLl2eT/PSLVHpbYUeABjP62EqxWpksOl2/fQfrGuVT1Vjm
QVoc345dKoKcNxVH1iuVg+/JYsmuPIpSmviFCKbH5IUlTWWyOYzWxZVdrZ/gIyXh
fY/vDL2yOdR9mTnHYAfsJ8IB2ABY4pDahC6Dbvh5JoN/vmsND2Wv2l+HIIdLTarj
R/n7+Rn6HLQmCJvgIWLniG6FxYxx4gqd/VVVaL7eJKYrcqvQq6VNZ/36Fgh3Ahdi
HnKxyer3K7vC8CGM3cNH/Dq/iGTNgTcX6pnhVepl/elSZTMDrxZcWbbA0nPhBe8J
5SWGEstv11OBi/JL3vGdTmV4ceZ/yIBg9pIGg4j0rH3hKT83G7O5E++PixKCmmMc
fZPCeAg=
=PGgQ
-----END PGP SIGNATURE-----
Merge tag 'sound-5.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound updates from Takashi Iwai:
"As the diffstat shows we've had again a lot of works done for this
cycle: the majority of changes are the continued componentization and
code refactoring in ASoC, the tree-wide PCM API updates and cleanups
and SOF updates while a few ASoC driver updates are seen, too.
Here we go, some highlights:
Core:
- Finally y2038 support landed to ALSA ABI; some ioctls have been
extended and lots of tricks were applied
- Applying the new managed PCM buffer API to all drivers; the API
itself was already merged in 5.5
- The already deprecated dimension support in ALSA control API is
dropped completely now
- Verification of ALSA control elements to catch API misuses
ASoC:
- Further code refactorings and moving things to the component level
- Lots of updates and improvements on SOF / Intel drivers; now
including common HDMI driver and SoundWire support
- New driver support for Ingenic JZ4770, Mediatek MT6660, Qualcomm
WCD934x and WSA881x, and Realtek RT700, RT711, RT715, RT1011,
RT1015 and RT1308
HD-audio:
- Improved ring-buffer communications using waitqueue
- Drop the superfluous buffer preallocation on x86
Others:
- Many code cleanups, mostly constifications over the whole tree
- USB-audio: quirks for MOTU, Corsair Virtuoso, Line6 Helix
- FireWire: code refactoring for oxfw and dice drivers"
* tag 'sound-5.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (638 commits)
ALSA: usb-audio: add quirks for Line6 Helix devices fw>=2.82
ALSA: hda: Add Clevo W65_67SB the power_save blacklist
ASoC: soc-core: remove null_snd_soc_ops
ASoC: soc-pcm: add soc_rtd_trigger()
ASoC: soc-pcm: add soc_rtd_hw_free()
ASoC: soc-pcm: add soc_rtd_hw_params()
ASoC: soc-pcm: add soc_rtd_prepare()
ASoC: soc-pcm: add soc_rtd_shutdown()
ASoC: soc-pcm: add soc_rtd_startup()
ASoC: rt1015: add rt1015 amplifier driver
ASoC: madera: Correct some kernel doc
ASoC: topology: fix soc_tplg_fe_link_create() - link->dobj initialization order
ASoC: Intel: skl_hda_dsp_common: Fix global-out-of-bounds bug
ASoC: madera: Correct DMIC only input hook ups
ALSA: cs46xx: fix spelling mistake "to" -> "too"
ALSA: hda - Add docking station support for Lenovo Thinkpad T420s
ASoC: Add MediaTek MT6660 Speaker Amp Driver
ASoC: dt-bindings: rt5645: add suppliers
ASoC: max98090: fix deadlock in max98090_dapm_put_enum_double()
ASoC: dapm: add snd_soc_dapm_put_enum_double_locked
...
Pull header cleanup from Ingo Molnar:
"This is a treewide cleanup, mostly (but not exclusively) with x86
impact, which breaks implicit dependencies on the asm/realtime.h
header and finally removes it from asm/acpi.h"
* 'core-headers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/ACPI/sleep: Move acpi_get_wakeup_address() into sleep.c, remove <asm/realmode.h> from <asm/acpi.h>
ACPI/sleep: Convert acpi_wakeup_address into a function
x86/ACPI/sleep: Remove an unnecessary include of asm/realmode.h
ASoC: Intel: Skylake: Explicitly include linux/io.h for virt_to_phys()
vmw_balloon: Explicitly include linux/io.h for virt_to_phys()
virt: vbox: Explicitly include linux/io.h to pick up various defs
efi/capsule-loader: Explicitly include linux/io.h for page_to_phys()
perf/x86/intel: Explicitly include asm/io.h to use virt_to_phys()
x86/kprobes: Explicitly include vmalloc.h for set_vm_flush_reset_perms()
x86/ftrace: Explicitly include vmalloc.h for set_vm_flush_reset_perms()
x86/boot: Explicitly include realmode.h to handle RM reservations
x86/efi: Explicitly include realmode.h to handle RM trampoline quirk
x86/platform/intel/quark: Explicitly include linux/io.h for virt_to_phys()
x86/setup: Enhance the comments
x86/setup: Clean up the header portion of setup.c
Tegra HDA has FIFO size which can hold upto 10 audio frames to support
DVFS. When HDA DMA RUN bit is set to 0 to stop the stream, the DMA RUN
bit will be cleared to 0 only after transferring all the remaining audio
frames queued up in the fifo. This is not in sync with spec which states
the controller will stop transmitting(output) in the beginning of the
next frame for the relevant stream.
The above behavior with Tegra HDA was resulting in machine check error
during the system suspend flow with active audio playback with below kernel
error logs.
[ 33.524583] mc-err: [mcerr] (hda) csr_hdar: EMEM address decode error
[ 33.531088] mc-err: [mcerr] status = 0x20000015; addr = 0x00000000
[ 33.537431] mc-err: [mcerr] secure: no, access-type: read, SMMU fault: none
This was due to the fifo has more than one audio frame when the DMA
RUN bit is set to 0 during system suspend flow and the timeout handling in
snd_hdac_stream_sync() was not designed to handle this scenario. So the
DMA will continue running even after timeout hit until all remaining
audio frames in the fifo are transferred, but the suspend flow will try
to reset the controller and turn off the hda clocks without the knowledge
of the DMA is still running and could result in mc-err.
The above issue can be resolved by doing stream reset with the help of
snd_hdac_stream_reset() which would ensure the DMA RUN bit is cleared
if the timeout was hit in snd_hdac_stream_sync().
Signed-off-by: Mohan Kumar <mkumard@nvidia.com>
Link: https://lore.kernel.org/r/20200128051508.26064-1-mkumard@nvidia.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
- remove ioremap_nocache given that is is equivalent to
ioremap everywhere
-----BEGIN PGP SIGNATURE-----
iQI/BAABCgApFiEEgdbnc3r/njty3Iq9D55TZVIEUYMFAl4vKHwLHGhjaEBsc3Qu
ZGUACgkQD55TZVIEUYMPGBAAuVNUZaZfWYHpiVP2oRcUQUguFiD3NTbknsyzV2oH
J9P0GfeENSKwE9OOhZ7XIjnCZAJwQgTK/ppQY5yiQ/KAtYyyXjXEJ6jqqjiTDInr
+3+I3t/LhkgrK7tMrb7ylTGa/d7KhaciljnOXC8+b75iddvM9I1z2pbHDbppZMS9
wT4RXL/cFtRb85AfOyPLybcka3f5P2gGvQz38qyimhJYEzHDXZu9VO1Bd20f8+Xf
eLBKX0o6yWMhcaPLma8tm0M0zaXHEfLHUKLSOkiOk+eHTWBZ3b/w5nsOQZYZ7uQp
25yaClbameAn7k5dHajduLGEJv//ZjLRWcN3HJWJ5vzO111aHhswpE7JgTZJSVWI
ggCVkytD3ESXapvswmACSeCIDMmiJMzvn6JvwuSMVB7a6e5mcqTuGo/FN+DrBF/R
IP+/gY/T7zIIOaljhQVkiEIIwiD/akYo0V9fheHTBnqcKEDTHV4WjKbeF6aCwcO+
b8inHyXZSKSMG//UlDuN84/KH/o1l62oKaB1uDIYrrL8JVyjAxctWt3GOt5KgSFq
wVz1lMw4kIvWtC/Sy2H4oB+RtODLp6yJDqmvmPkeJwKDUcd/1JKf0KsZ8j3FpGei
/rEkBEss0KBKyFAgBSRO2jIpdj2epgcBcsdB/r5mlhcn8L77AS6mHbA173kY4pQ/
Kdg=
=TUCJ
-----END PGP SIGNATURE-----
Merge tag 'ioremap-5.6' of git://git.infradead.org/users/hch/ioremap
Pull ioremap updates from Christoph Hellwig:
"Remove the ioremap_nocache API (plus wrappers) that are always
identical to ioremap"
* tag 'ioremap-5.6' of git://git.infradead.org/users/hch/ioremap:
remove ioremap_nocache and devm_ioremap_nocache
MIPS: define ioremap_nocache to ioremap
Multiple Intel ASoC machine drivers repeat the same pattern in their
.late_probe() methods: they first check whether the common HDMI codec
driver is used, if not, they proceed by linking the legacy HDMI
driver to each HDMI port. While doing that they use some
inconsistent code:
1. after the loop they check, whether the list contained at least one
element and if not, they return an error. However, the earlier
code to use the common HDMI driver uses the first element of the
same list without checking. To fix this we move the check to the
top of the function.
2. some of those .late_probe() implementations execute code, only
needed for the common HDMI driver, before checking, whether the
driver is used. Move the code to after the check.
3. Some of those functions also perform a redundant initialisation of
the "err" variable.
This patch fixes those issues.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200124213625.30186-8-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
jsl_desc missed default_fw_name, this will fail the probe in
nocodec or generice HDA mode due the firmware path is intel/sof/(null)
Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200124213625.30186-6-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Check if DMA pages were successfully allocated in initialization
before calling free. For many types of memory (like sgbufs)
the extra free is harmless, but not all backends track allocation
state, so add an explicit check.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200124213625.30186-5-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The initial intent of releasing resources in the .remove does not work
well with HDaudio codecs. If the probe_continue() fails in a work
queue, e.g. due to missing firmware or authentication issues, we don't
release any resources, and as a result the kernel oopses during
suspend operations.
The suggested fix is to release all resources during errors in
probe_continue(), and use fw_state to track resource allocation
state, so that .remove does not attempt to release the same
hardware resources twice. PM operations are also modified so that
no action is done if DSP resources have been freed due to
an error at probe.
Reported-by: Takashi Iwai <tiwai@suse.de>
Co-developed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Bugzilla: http://bugzilla.suse.com/show_bug.cgi?id=1161246
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200124213625.30186-4-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
It is possible to create invalid topology that will cause a kernel
Oops when trying to allocate buffers for a NULL substream.
Specifically such an Oops was caused by a topology, where a DAI on a
capture pipeline was referencing the PCM ID from a playback pipeline.
Fix the Oops by explicitly checking for NULL.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200124213625.30186-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Change HDA probe behaviour slightly so that i915 power is not
turned off if i915 audio codecs are found in the initial probe done
by SOF Intel driver, and power is kept on until HDA codec driver
probe runs.
This will reduce number of mode sets on platforms with low
minimum CDCLK (like GLK) and brings the SOF probe sequence closer
to legacy HDA driver in terms of i915 audio codec power management.
BugLink: https://github.com/thesofproject/linux/issues/1642
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200120160117.29130-3-kai.vehmanen@linux.intel.com
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The current interface to control i915 display power is misleading.
The hda_codec_i915_get() and hda_codec_i915_put() names suggest
a refcounting based interface. This is confusing as no refcounting
is done and the underlying HDAC library interface does not support
refcounts eithers.
Clarify the code by replacing the functions with a single
hda_codec_i915_display_power() that is aligned with
snd_hdac_display_power().
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200120160117.29130-2-kai.vehmanen@linux.intel.com
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
A pretty big release this time around, a lot of new drivers and both
Morimoto-san and Takashi were doing subsystem wide updates as well:
- Further big refactorings from Morimoto-san simplifying the core
interfaces and moving things to the component level.
- Transition of drivers to managed buffer allocation and removal of
redundant PCM ioctls.
- New driver support for Ingenic JZ4770, Mediatek MT6660, Qualcomm
WCD934x and WSA881x, and Realtek RT700, RT711, RT715, RT1011, RT1015
and RT1308.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl4vEpMTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0KN+B/47oBWAdJYYSrwXyQtlQgpJv/o9fEB+
OnhlvCVjC3gPc8rBnUmgyUNYpBEqtmIH1CVdG/2844e0w1g9JJ5UFPp0SJWZp3Nu
toRznG64JKE0l9qZsLMOKXbPAtb/KvANM1dy7eTTtbHQhP4jA72f3jmDKfLDa/Xc
vsOBWhBKKAkffu9AIYuMLG2sxuyw0lX3T1yxx7BfJE9NzHXwhYaBP7loLoQn33xg
9DrjNuT+gTadUZKsZRw0kNBWC9IIryZ9oGFrfORI51G41sD2DgY3u0xd+Tm44XXe
UPwUFxDSMslpIKKu6jn/14TjbOZX2i2D2bYs8DRcppA38Ltdc70DzbgV
=C1LS
-----END PGP SIGNATURE-----
Merge tag 'asoc-v5.6' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Updates for v5.6
A pretty big release this time around, a lot of new drivers and both
Morimoto-san and Takashi were doing subsystem wide updates as well:
- Further big refactorings from Morimoto-san simplifying the core
interfaces and moving things to the component level.
- Transition of drivers to managed buffer allocation and removal of
redundant PCM ioctls.
- New driver support for Ingenic JZ4770, Mediatek MT6660, Qualcomm
WCD934x and WSA881x, and Realtek RT700, RT711, RT715, RT1011, RT1015
and RT1308.
With firmware 2.82 Line6 changed the usb id of some of the Helix
devices but the quirks is still needed.
Add it to the quirk list for line6 helix family of devices.
Thanks to Jens for pointing out the missing ids.
Signed-off-by: Nicola Lunghi <nick83ola@gmail.com>
Link: https://lore.kernel.org/r/20200125150917.5040-1-nick83ola@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Commit 08df0d9a00 ("ASoC: max98090: revert "ASoC: max98090: fix lockdep
warning"") provided a good rationale for removing separate lock for the
SHDN register access. However it restored the lockdep warning during the
system boot. To silence the lockdep warning, mark the mutex taken in the
max98090_shdn_save() function with the lockdep class dedicated for the
runtime DAPM operations: SND_SOC_DAPM_CLASS_RUNTIME. This finally fixes
the following lockdep warning observed on Exynos4412-based Odroid U3
board:
======================================================
WARNING: possible circular locking dependency detected
5.5.0-rc7-next-20200123 #7329 Not tainted
------------------------------------------------------
alsactl/1105 is trying to acquire lock:
ed4f7cf4 (&card->dapm_mutex){+.+.}, at: max98090_shdn_save+0x1c/0x28
but task is already holding lock:
edb8d49c (&card->controls_rwsem){++++}, at: snd_ctl_ioctl+0xcc/0xbb8
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&card->controls_rwsem){++++}:
snd_ctl_add_replace+0x3c/0x84
dapm_create_or_share_kcontrol+0x24c/0x2e0
snd_soc_dapm_new_widgets+0x308/0x594
snd_soc_bind_card+0x834/0xa94
devm_snd_soc_register_card+0x34/0x6c
odroid_audio_probe+0x288/0x34c
platform_drv_probe+0x6c/0xa4
really_probe+0x200/0x48c
driver_probe_device+0x78/0x1f8
bus_for_each_drv+0x74/0xb8
__device_attach+0xd4/0x16c
bus_probe_device+0x88/0x90
deferred_probe_work_func+0x3c/0xd0
process_one_work+0x230/0x7bc
worker_thread+0x44/0x524
kthread+0x130/0x164
ret_from_fork+0x14/0x20
0x0
-> #0 (&card->dapm_mutex){+.+.}:
lock_acquire+0xe8/0x270
__mutex_lock+0x9c/0xb18
mutex_lock_nested+0x1c/0x24
max98090_shdn_save+0x1c/0x28
max98090_put_enum_double+0x20/0x40
snd_ctl_ioctl+0x190/0xbb8
ksys_ioctl+0x484/0xb10
ret_fast_syscall+0x0/0x28
0xbede0564
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&card->controls_rwsem);
lock(&card->dapm_mutex);
lock(&card->controls_rwsem);
lock(&card->dapm_mutex);
*** DEADLOCK ***
1 lock held by alsactl/1105:
#0: edb8d49c (&card->controls_rwsem){++++}, at: snd_ctl_ioctl+0xcc/0xbb8
stack backtrace:
CPU: 2 PID: 1105 Comm: alsactl Not tainted 5.5.0-rc7-next-20200123 #7329
Hardware name: Samsung Exynos (Flattened Device Tree)
[<c01126f0>] (unwind_backtrace) from [<c010e1e8>] (show_stack+0x10/0x14)
[<c010e1e8>] (show_stack) from [<c0b5234c>] (dump_stack+0xb4/0xe0)
[<c0b5234c>] (dump_stack) from [<c018a610>] (check_noncircular+0x1ec/0x208)
[<c018a610>] (check_noncircular) from [<c018ca2c>] (__lock_acquire+0x1210/0x25ec)
[<c018ca2c>] (__lock_acquire) from [<c018e728>] (lock_acquire+0xe8/0x270)
[<c018e728>] (lock_acquire) from [<c0b71928>] (__mutex_lock+0x9c/0xb18)
[<c0b71928>] (__mutex_lock) from [<c0b723c0>] (mutex_lock_nested+0x1c/0x24)
[<c0b723c0>] (mutex_lock_nested) from [<c086097c>] (max98090_shdn_save+0x1c/0x28)
[<c086097c>] (max98090_shdn_save) from [<c08613f8>] (max98090_put_enum_double+0x20/0x40)
[<c08613f8>] (max98090_put_enum_double) from [<c0833f20>] (snd_ctl_ioctl+0x190/0xbb8)
[<c0833f20>] (snd_ctl_ioctl) from [<c02cae14>] (ksys_ioctl+0x484/0xb10)
[<c02cae14>] (ksys_ioctl) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
Exception stack(0xed331fa8 to 0xed331ff0)
...
Fixes: 08df0d9a00 ("ASoC: max98090: revert "ASoC: max98090: fix lockdep warning"")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200123134046.9769-1-m.szyprowski@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
All rtd->dai_link callback functions are controlled by soc_rtd_xxxx(),
and checking rtd->dai_link->ops.
We don't need to have null_snd_soc_ops anymore.
This patch removes it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87zhegl3oz.wl-kuninori.morimoto.gx@renesas.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add soc_rtd_trigger() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/871rrsmi9j.wl-kuninori.morimoto.gx@renesas.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add soc_rtd_hw_free() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/8736c8mi9n.wl-kuninori.morimoto.gx@renesas.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add soc_rtd_hw_params() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/874kwomi9r.wl-kuninori.morimoto.gx@renesas.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add soc_rtd_prepare() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/875zh4mi9v.wl-kuninori.morimoto.gx@renesas.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add soc_rtd_shutdown() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/877e1kmi9z.wl-kuninori.morimoto.gx@renesas.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add soc_rtd_startup() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/878sm0mia4.wl-kuninori.morimoto.gx@renesas.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The code which checks the return value for snd_soc_add_dai_link() call
in soc_tplg_fe_link_create() moved the snd_soc_add_dai_link() call before
link->dobj members initialization.
While it does not affect the latest kernels, the old soc-core.c code
in the stable kernels is affected. The snd_soc_add_dai_link() function uses
the link->dobj.type member to check, if the link structure is valid.
Reorder the link->dobj initialization to make things work again.
It's harmless for the recent code (and the structure should be properly
initialized before other calls anyway).
The problem is in stable linux-5.4.y since version 5.4.11 when the
upstream commit 76d2703649 was applied.
Fixes: 76d2703649 ("ASoC: topology: Check return value for snd_soc_add_dai_link()")
Cc: Dragos Tarcatu <dragos_tarcatu@mentor.com>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20200122190752.3081016-1-perex@perex.cz
Signed-off-by: Mark Brown <broonie@kernel.org>
Both the data and clock should be connected to both the left and right
inputs for DMIC only inputs, add the missing routes.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200122104143.16725-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Lenovo Thinkpad T420s uses the same codec as T420, so apply the
same quirk to enable audio output on a docking station.
Signed-off-by: Peter Große <pegro@friiks.de>
Link: https://lore.kernel.org/r/20200122180106.9351-1-pegro@friiks.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The MT6660 is a boosted BTL class-D amplifier with V/I sensing.
A built-in DC-DC step-up converter is used to provide efficient
power for class-D amplifier with multi-level class-G operation.
The digital audio interface supports I2S, left-justified,
right-justified, TDM and DSP A/B format for audio in with a data
out used for chip information like voltage sense and current
sense, which are able to be monitored via DATAO through proper
Signed-off-by: Jeff Chang <jeff_chang@richtek.com>
Link: https://lore.kernel.org/r/1579153597-23286-1-git-send-email-richtek.jeff.chang@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 62d5ae4caf ("ASoC: max98090: save and restore SHDN when
changing sensitive registers SHDN bit") uses dapm_mutex to protect SHDN
bit. However, snd_soc_dapm_put_enum_double() in
max98090_dapm_put_enum_double() acquires the dapm_mutex again which
cause a deadlock.
Use snd_soc_dapm_put_enum_double_locked() instead to fix the deadlock.
Fixes: 62d5ae4caf ("ASoC: max98090: save and restore SHDN when changing sensitive registers SHDN bit")
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200117073814.82441-4-tzungbi@google.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 2dc98af62c ("ASoC: max98090: fix lockdep warning") introduced
a helpful-less small lock: shdn_lock. Reverts the commit.
Reasons:
1. Lockdep should not be happy by either the original or current code.
From lockdep's point of view, there is a lock inversion anyway.
Let d = dapm_mutex, c = controls_rwsem, s = shdn_lock,
From the reported calling stack: lock acquisition order of
snd_soc_register_card() is: d -> c.
> snd_ctl_add_replace+0x3c/0x84
> dapm_create_or_share_kcontrol+0x24c/0x2e0
> snd_soc_dapm_new_widgets+0x308/0x594
> snd_soc_bind_card+0x80c/0xad4
> devm_snd_soc_register_card+0x34/0x6c
If calling snd_soc_dapm_put_enum_double() in kcontrol's put (e.g.
SOC_DAPM_ENUM_EXT), lock acquisition order is: c -> d. Note that,
snd_soc_dapm_put_enum_double() acquires d.
The possible lock inversion is always there if registering sound card
and putting mixer control happen at the same time. In fact, it never
happens because the control device don't show up to the userspace until
the sound card build success.
Commit 2dc98af62c ("ASoC: max98090: fix lockdep warning") changes the
order to: c -> s -> d. The lock inversion is still there.
2. Commit 62d5ae4caf ("ASoC: max98090: save and restore SHDN when
changing sensitive registers SHDN bit") designed to use dapm_mutex to
protect SHDN bit. Use a separate lock breaks the protection.
DAPM changes SHDN bit automatically when it finds the path. Thus, any
code wants to change the SHDN bit, need to acquire the dapm_mutex first.
> SND_SOC_DAPM_SUPPLY("SHDN", M98090_REG_DEVICE_SHUTDOWN,
> M98090_SHDNN_SHIFT, 0, NULL, 0),
Fixes: 2dc98af62c ("ASoC: max98090: fix lockdep warning")
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200117073814.82441-2-tzungbi@google.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Now, snd_soc_dai_driver::bus_control is used for how to resume.
But, no driver which has bus_control has DAI driver suspend/resume
support.
This patch removes pointless bus_control from ALSA SoC.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87pnffx7i4.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Historically, CPU and Codec were implemented different, but now it is
merged as Component.
ALSA SoC is supporting suspend/resume at DAI and Component level.
The method is like below.
1) Suspend/Resume all CPU DAI if bus-control was 0
2) Suspend/Resume all Component
3) Suspend/Resume all CPU DAI if bus-control was 1
Historically 2) was Codec special operation.
Because CPU and Codec were merged into Component,
CPU suspend/resume has 3 chance to suspend(= 1/2/3), but
Codec suspend/resume has 1 chance (= 2).
Here, DAI side suspend/resume is caring bus-control, but no driver
which is supporting suspend/resume is setting bus-control.
This means 3) was never used.
Here, used parameter for suspend/resume component->dev and dai->dev are
same pointer.
For that reason, we can merge DAI and Component suspend/resume.
One note is that we should use 2), because it is caring BIAS level.
This patch removes 1) and 3).
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87r1zvx7i8.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87sgkbx7ic.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can swtcih all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87tv4rx7ij.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87wo9nx7it.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87y2u3x7iy.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87zhejx7j4.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/871rrvym3p.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/8736cbym3x.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/874kwrym42.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/875zh7ym48.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/877e1nym4e.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/878sm3ym4j.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87a76jym4p.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87d0bfym53.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87blqzym4w.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove the return value checking, that is to align with the code
before adding snd_dmaengine_pcm_refine_runtime_hwparams function.
Otherwise it causes a regression on the HiKey board:
[ 17.721424] hi6210_i2s f7118000.i2s: ASoC: can't open component f7118000.i2s: -6
Fixes: e957204e73 ("ASoC: pcm_dmaengine: Extract snd_dmaengine_pcm_refine_runtime_hwparams")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reported-by: John Stultz <john.stultz@linaro.org>
Link: https://lore.kernel.org/r/1579505286-32085-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Crash happens in snd_soc_dapm_new_dai() when substream->private_data
access is made and substream is NULL here. This is seen for DAIs where
only playback or capture stream is defined. This seems to be happening
for codec2codec DAI link.
Both playback and capture are 0 during soc_new_pcm(). This is probably
happening because cpu_dai and codec_dai are both validated either for
SNDRV_PCM_STREAM_PLAYBACK or SNDRV_PCM_STREAM_CAPTURE.
Shouldn't be playback = 1 when,
- playback stream is available for codec_dai AND
- capture stream is available for cpu_dai
and vice-versa for capture = 1?
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/1579443563-12287-1-git-send-email-spujar@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The initial snd_hda_get_sub_node() can fail on certain
devices (e.g. some Chromebook models using Intel GLK).
The failure rate is very low, but as this is is part of
the probe process, end-user impact is high.
In observed cases, related hardware status registers have
expected values, but the node query still fails. Retrying
the node query does seem to help, so fix the problem by
adding retry logic to the query. This does not impact
non-Intel platforms.
BugLink: https://github.com/thesofproject/linux/issues/1642
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200120160117.29130-4-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Like many other drivers, HD-audio drivers also do PCM buffer
preallocation to assure the buffer pages allocated at the early boot
stage. This step is useful for platforms that may fail to allocate
the PCM hardware buffers -- which is mostly for either large
continuous pages or with the specific DMA mask (like emu10k1).
OTOH, when a buffer is allocated as SG-buffer and the DMA mask is
either 32 or 64 bits, the allocation almost never fails unless it hits
the real OOM situation. In such a case, we don't need the
preallocation inevitably unlike the cases above.
That said, we may drop the preallocation for HD-audio that does
allocate via SG-buffers, and the patch achieves it.
However, there is one caveat: the buffer allocation behavior depends
on CONFIG_SND_DMA_SGBUF, and it falls back to the continuous pages
when it's not set. And, currently this SG buffer allocation is
enabled only on x86 platforms. So, covering those fall-outs, the
patch adjusts CONFIG_SND_HDA_PREALLOC_SIZE depending on the condition,
and keeps the old behavior as-is for non-x86 platforms.
On x86, the kconfig item is no longer adjustable but always set to
zero for disabling the preallocation. You can still enable the
preallocation via procfs interface at any time later, too.
Link: https://lore.kernel.org/r/20200120124423.11862-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently, the available buffer allocation size for a PCM stream
depends on the preallocated size; when a buffer has been preallocated,
the max buffer size is set to that size, so that application won't
re-allocate too much memory. OTOH, when no preallocation is done,
each substream may allocate arbitrary size of buffers as long as
snd_pcm_hardware.buffer_bytes_max allows -- which can be quite high,
HD-audio sets 1GB there.
It means that the system may consume a high amount of pages for PCM
buffers, and they are pinned and never swapped out. This can lead to
OOM easily.
For avoiding such a situation, this patch adds the upper limit per
card. Each snd_pcm_lib_malloc_pages() and _free_pages() calls are
tracked and it will return an error if the total amount of buffers
goes over the defined upper limit. The default value is set to 32MB,
which should be really large enough for usual operations.
If larger buffers are needed for any specific usage, it can be
adjusted (also dynamically) via snd_pcm.max_alloc_per_card option.
Setting zero there means no chceck is performed, and again, unlimited
amount of buffers are allowed.
Link: https://lore.kernel.org/r/20200120124423.11862-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It turned out that the recent simplification of HD-audio bus access
helpers caused a regression on the virtual HD-audio device on QEMU
with ARM platforms. The driver got a CORB/RIRB timeout and couldn't
probe any codecs.
The essential difference that caused a problem was the enforced
aligned MMIO accesses by simplification. Since snd-hda-tegra driver
is enabled on ARM, it enables CONFIG_SND_HDA_ALIGNED_MMIO, which makes
the all HD-audio drivers using the aligned MMIO accesses. While this
is mandatory for snd-hda-tegra, it seems that snd-hda-intel on ARM
gets broken by this access pattern.
For addressing the regression, this patch introduces a new flag,
aligned_mmio, to hdac_bus object, and applies the aligned MMIO only
when this flag is set. This change affects only platforms with
CONFIG_SND_HDA_ALIGNED_MMIO set, i.e. mostly only for ARM platforms.
Unfortunately the patch became a big bigger than it should be, just
because the former calls didn't take hdac_bus object in the argument,
hence we had to extend the call patterns.
Fixes: 19abfefd4c ("ALSA: hda: Direct MMIO accesses")
BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1161152
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200120104127.28985-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This became bigger than I have hoped for rc7. But, the only large LOC
is for stm32 fixes that are simple rewriting of register access
helpers, while the rest are all nice and small fixes:
- A few ASoC fixes for the remaining probe error handling bugs
- ALSA sequencer core fix for racy proc file accesses
- Revert the option rename of snd-hda-intel to make compatible again
- Various device-specific fixes
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAl4gjbEOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE8Pow/+KXlxZDprRwaW5jX23k7OOOdZOjyrM+XNNH1J
ubCV5jHfZqT6FK2Ewo6ytxDOE7liiAZCs1r5D7of8sRHPVeMfgyRNdL4MbirR03n
eGzREtynfPXymcnaKZuuantFNl4rq3ovwCUOTiqNgTdONZzakm3bISMf5RLF0SBU
wuImY3PHepcjah3BXBTJHj8V9KpmDasd15DcrK0j/W+oS4eNnxSCoH4gzAwjAuDO
v2bEsF/yXGDhriyl/squJjVBnNOkzn/fyRAQl7RGe8pNa4PWIvbAaqd5qaIch4EH
perJfnvhB5SoB/s7mJ3jwnjA/vx0VKkCOw7Wufr/3+i1gKsuDbkvh8eaoN0/rnNk
gn56hLux7nnbOW5uzVG12PekIf3T7uJMM7mMZGAMOeQpWK6xCpDHHlC/1rZd+idy
SUgkqHEhQl9Qu5d7c7KkTy408FOzhaL4HZX5wqSghPUj2mFrWZGxpQvLlD1FYCE2
NuFKzPNYaeLbUyhJJ2HBmjEov0R3ASZzVYx/fRarc+JET7jI/hyWfBJ+oe1qy1Ff
X7gDrLpbXd61lgtCALlv9K1v5Ap7FSkAEXiHI4jtj/9m0yN/XTp5pqjd4itW7ZR9
2EuQrsysh1JimFBauNdLVRCPooPkAqiEeWscMjqgBth2l7BhinYoXIMcA+fchUgC
up9VJeQ=
=M4pi
-----END PGP SIGNATURE-----
Merge tag 'sound-5.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"This became bigger than I have hoped for rc7. But, the only large LOC
is for stm32 fixes that are simple rewriting of register access
helpers, while the rest are all nice and small fixes:
- A few ASoC fixes for the remaining probe error handling bugs
- ALSA sequencer core fix for racy proc file accesses
- Revert the option rename of snd-hda-intel to make compatible again
- Various device-specific fixes"
* tag 'sound-5.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: seq: Fix racy access for queue timer in proc read
ALSA: usb-audio: fix sync-ep altsetting sanity check
ASoC: msm8916-wcd-digital: Reset RX interpolation path after use
ASoC: msm8916-wcd-analog: Fix MIC BIAS Internal1
ASoC: cros_ec_codec: Make the device acpi compatible
ASoC: sti: fix possible sleep-in-atomic
ASoC: msm8916-wcd-analog: Fix selected events for MIC BIAS External1
ASoC: hdac_hda: Fix error in driver removal after failed probe
ASoC: SOF: Intel: fix HDA codec driver probe with multiple controllers
ASoC: SOF: Intel: lower print level to dbg if we will reinit DSP
ALSA: dice: fix fallback from protocol extension into limited functionality
ALSA: firewire-tascam: fix corruption due to spin lock without restoration in SoftIRQ context
ALSA: hda: Rename back to dmic_detect option
ASoC: stm32: dfsdm: fix 16 bits record
ASoC: stm32: sai: fix possible circular locking
ASoC: Fix NULL dereference at freeing
ASoC: Intel: bytcht_es8316: Fix Irbis NB41 netbook quirk
ASoC: rt5640: Fix NULL dereference on module unload
The snprintf calls filling cht_rt5645_cpu_dai_name /
cht_rt5645_codec_aif_name always fill them with the same string
("ssp0-port" resp "rt5645-aif2") so instead of keeping these buffers
around and making cpus->dai_name / codecs->dai_name point to this,
simply update the *->dai_name pointers to directly point to a string
constant containing the desired string.
Signed-off-by: Damian van Soelen <dj.vsoelen@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200115164619.101705-5-hdegoede@redhat.com
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The snprintf calls filling byt_rt56*_codec_aif_name/byt_rt56*_cpu_dai_name
always fill them with the same string ("rt56*-aif2" resp. ssp0-port").
So instead of keeping these buffers around and making codecs->dai_name /
cpus->dai_name point to them, simply update the *->dai_name pointers to
directly point to a string constant containing the desired string.
Signed-off-by: Jordy Ubink <jordyubink@hotmail.nl>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200115164619.101705-4-hdegoede@redhat.com
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Arvind Sankar