The commit c31427d0d2 ("ALSA: hda: No preallocation on x86
platforms") changed CONFIG_SND_HDA_PREALLOC_SIZE setup and its default
to zero for x86, as the preallocation should work almost all cases.
However, this expectation was too naive; some applications try to
allocate as the max buffer size as possible, and it leads to the
memory exhaustion. More badly, the commit changed the kconfig no
longer adjustable for x86, so you can't fix it statically (although it
can be still adjusted via procfs).
So, practically seen, it's more recommended to set a reasonable limit
for x86, too. This patch follows to that experience, and changes the
default to 2048 and allow the kconfig adjustable again.
Fixes: c31427d0d2 ("ALSA: hda: No preallocation on x86 platforms")
Cc: <stable@vger.kernel.org>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207223
Link: https://lore.kernel.org/r/20200413201919.24241-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_hdac_codec_modalias() truncates the string to the given size and
returns its size, but it returned a wrong size from snprintf().
snprintf() returns the would-be-output size, not the actual size.
Use scnprintf() instead to return the correct size.
Link: https://lore.kernel.org/r/20200313130241.8970-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A few fixes sent in since the merge window, none of them with global
impact but all important for the users they affect.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl5L1EQTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0PeSB/9iL7rCZE89d15gmjrLzLvBFp1zXlIZ
l67F6e0RN8kw4/Au1T8noa3hzuvP7hAr0rd3dhNsFKzi0JMkPTpxA17H0qbbClSy
S7aS6Kg85thzZ51xNIw8LrzfWwI+QRMJJDLPsLET552/An36QVz+XeeMRnxkIJl5
toIAF0Ij14EH/57Sl56JRaYIkNfyBy9Nf1ilI9CDIoclE9cyT7tFvKabBDjFclOJ
bkpvP0fR1rFA0VHU/4Asc6zOj7gFMTOFkZs0Nhuuzq2FB+mtGrvvTMfR3xoaBY7P
qHnnBkBiEIXj1frMA2Ar6AJqOIuEPg8bju36k4sugeDZ/Nq7ywPkr0Ml
=m9Gm
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v5.6-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v5.6
A few fixes sent in since the merge window, none of them with global
impact but all important for the users they affect.
Some code in HD-audio driver calls snprintf() in a loop and still
expects that the return value were actually written size, while
snprintf() returns the expected would-be length instead. When the
given buffer limit were small, this leads to a buffer overflow.
Use scnprintf() for addressing those issues. It returns the actually
written size unlike snprintf().
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200218091409.27162-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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>
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>
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>
Make W=1 throws a lot of warnings, with multiple misalignments between
function params and their descriptions.
Signed-off-by: Keyon Jie <yang.jie@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200113205638.27338-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In the commit 8e85def572 ("ALSA: hda: enable regmap internal
locking"), we re-enabled the regmap lock due to the reported
regression that showed the possible concurrent accesses. It was a
temporary workaround, and there are still a few opened races even
after the revert. In this patch, we cover those still opened windows
with a proper mutex lock and disable the regmap internal lock again.
First off, the patch introduces a new snd_hdac_device.regmap_lock
mutex that is applied for each snd_hdac_regmap_*() call, including
read, write and update helpers. The mutex is applied carefully so
that it won't block the self-power-up procedure in the helper
function. Also, this assures the protection for the accesses without
regmap, too.
The snd_hdac_regmap_update_raw() is refactored to use the standard
regmap_update_bits_check() function instead of the open-code. The
non-regmap case is still open-coded but it's an easy part. The all
read and write operations are in the single mutex protection, so it's
now race-free.
In addition, a couple of new helper functions are added:
snd_hdac_regmap_update_raw_once() and snd_hdac_regmap_sync(). Both
are called from HD-audio legacy driver. The former is to initialize
the given verb bits but only once when it's not initialized yet. Due
to this condition, the function invokes regcache_cache_only(), and
it's now performed inside the regmap_lock (formerly it was racy) too.
The latter function is for simply invoking regcache_sync() inside the
regmap_lock, which is called from the codec resume call path.
Along with that, the HD-audio codec driver code is slightly modified /
simplified to adapt those new functions.
And finally, snd_hdac_regmap_read_raw(), *_write_raw(), etc are
rewritten with the helper macro. It's just for simplification because
the code logic is identical among all those functions.
Tested-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200109090104.26073-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Apply const prefix to the remaining possible places: the string
tables, the rate tables, the verb tables, the index tables, etc.
Just for minor optimization and no functional changes.
Link: https://lore.kernel.org/r/20200105144823.29547-10-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Taking the 5.5 devel branch back into the main devel branch.
A USB-audio fix needs to be adjusted to adapt the changes that have
been formerly applied for stop_sync.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The commit e38e486d66 ("ALSA: hda: Modify stream stripe mask only
when needed") tried to address the regression by the unconditional
application of the stripe mask, but this caused yet another
regression for the previously working devices. Namely, the patch
clears the azx_dev->stripe flag at snd_hdac_stream_clear(), but this
may be called multiple times before restarting the stream, so this
ended up with clearance of the flag for the whole time.
This patch fixes the regression by moving the azx_dev->stripe flag
clearance at the counter-part, the close callback of HDMI codec
driver instead.
Fixes: e38e486d66 ("ALSA: hda: Modify stream stripe mask only when needed")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205855
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204477
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191214175217.31852-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Now most of the get_response handling became quite similar between
HDA-core and legacy drivers, and the only differences are:
- the handling of extra-long polling delay for some codecs
- the debug message for the stalled communication
and both are worth to share in the common code.
This patch unifies the code into snd_hdac_bus_get_response(), and use
this from the legacy get_response callback. It results in a good
amount of code reduction in the end.
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20191212191101.19517-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch implements the same logic that was done for the legacy
HD-audio controller driver by the commit 88452da92b ("ALSA: hda: Use
standard waitqueue for RIRB wakeup") to the HDA-core helper code,
too. This makes snd_hdac_bus_get_response() waiting for the response
with bus->rirb_wq instead of polling when bus->polling is false.
It'll save both CPU time and response latency.
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20191212191101.19517-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The HD-audio CORB/RIRB communication was programmed in a way that was
documented in the reference in decades ago, which is essentially a
polling in the waiter side. It's working fine but costs CPU cycles on
some platforms that support only slow communications. Also, for some
platforms that had unreliable communications, we put longer wait time
(2 ms), which accumulate quite long time if you execute many verbs in
a shot (e.g. at the initialization or resume phase).
This patch attempts to improve the situation by introducing the
standard waitqueue in the RIRB waiter side instead of polling. The
test results on my machine show significant improvements. The time
spent for "cat /proc/asound/card*/codec#*" were changed like:
* Intel SKL + Realtek codec
before the patch:
0.00user 0.04system 0:00.10elapsed 40.0%CPU
after the patch:
0.00user 0.01system 0:00.10elapsed 10.0%CPU
* Nvidia GP107GL + Nvidia HDMI codec
before the patch:
0.00user 0.00system 0:02.76elapsed 0.0%CPU
after the patch:
0.00user 0.00system 0:00.01elapsed 17.0%CPU
So, for Intel chips, the total time is same, while the total time is
greatly reduced (from 2.76 to 0.01s) for Nvidia chips.
The only negative data here is the increase of CPU time for Nvidia,
but this is the unavoidable cost for faster wakeups, supposedly.
Link: https://lore.kernel.org/r/20191210145727.22054-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent commit in HD-audio stream management for changing the
stripe control seems causing a regression on some platforms. The
stripe control is currently used only by HDMI codec, and applying the
stripe mask unconditionally may lead to scratchy and static noises as
seen on some MacBooks.
For addressing the regression, this patch changes the stream
management code to apply the stripe mask conditionally only when the
codec driver requested.
Fixes: 9b6f7e7a29 ("ALSA: hda: program stripe bits for controller")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204477
Tested-by: Michael Pobega <mpobega@neverware.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191202074947.1617-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Since we apply the own mutex (bus->cmd_mutex) in HDA core side, the
internal locking in regmap is superfluous. This patch adds the flag
to indicate that.
Also, an infamous side-effect by this change is that it disables the
regmap debugfs, too, and this is seen rather good; the regmap debugfs
isn't quite useful for HD-audio as it provides the very sparse
registers and its debugfs access tends to lead to the way too high
resource usages or sometimes hang up. So it'd be rather safe to
disable it altogether.
Link: https://lore.kernel.org/r/2029139028.10333037.1572874551626.JavaMail.zimbra@redhat.com
Link: https://lore.kernel.org/r/20191105081806.4896-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent addition of snd_intel_dsp_driver_probe() check caused a
spurious kernel warning when the driver is loaded for a non-Intel
hardware due to snd_BUG_ON(). Moreover, for such a hardware, we
should always return SND_INTEL_DSP_DRIVER_ANY, not check the
dsp_driver option at all.
This patch fixes these issues for non-Intel devices.
Fixes: 82d9d54a6c ("ALSA: hda: add Intel DSP configuration / probe code")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20191028130634.3501-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit caa8422d01.
It turned out that this commit caused a regression at shutdown /
reboot, as the synchronize_irq() calls seems blocking the whole
shutdown. Also another part of the change about shuffling the call
order looks suspicious; the azx_stop_chip() call disables the CORB /
RIRB while the others may still need the CORB/RIRB update.
Since the original commit itself was a cargo-fix, let's revert the
whole patch.
Fixes: caa8422d01 ("ALSA: hda: Flush interrupts on disabling")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205333
BugLinK: https://bugs.freedesktop.org/show_bug.cgi?id=111174
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://lore.kernel.org/r/20191028081056.22010-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reshuffle list of devices by historical order and add correct
information as needed.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20191022174313.29087-2-perex@perex.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For distributions, we need one place where we can decide
which driver will be activated for the auto-configation of the
Intel's HDA hardware with DSP. Actually, we cover three drivers:
* Legacy HDA
* Intel SST
* Intel Sound Open Firmware (SOF)
All those drivers registers similar PCI IDs, so the first
driver probed from the PCI stack can win. But... it is not
guaranteed that the correct driver wins.
This commit changes Intel's NHLT ACPI module to a common
DSP probe module for the Intel's hardware. All above sound
drivers calls this code. The user can force another behaviour
using the module parameter 'dsp_driver' located in
the 'snd-intel-dspcfg' module.
This change allows to add specific dmi checks for the specific
systems. The examples are taken from the pull request:
https://github.com/thesofproject/linux/pull/927
Tested on Lenovo Carbon X1 7th gen.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191022174313.29087-1-perex@perex.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fix potential DMA hang upon starting playback on devices in HDA mode
on Intel platforms (Gemini Lake/Whiskey Lake/Comet Lake/Ice Lake). It
doesn't affect platforms before Gemini Lake or any Intel device in
non-HDA mode.
The reset value for the LOSDIV register is all output streams valid.
Clear this register to invalidate non-existent streams when the bus
is powered up.
Signed-off-by: Rander Wang <rander.wang@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20190930142945.7805-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit ee5f85d929 ("ALSA: hda: Add codec on bus address
table lately"). The commit caused several regression since I've
overlooked that the function doesn't manage only the caddr_tbl but
also the codec linked list that is referred indirectly in the other
drivers.
Revert for now to make everything back to work.
Fixes: ee5f85d929 ("ALSA: hda: Add codec on bus address table lately")
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Drop EXPORT_SYMBOL*() from a few more stuff in HD-audio core that
aren't used outside. Particular the unsol event handler can be
staticized now because the recent change removed all external
callers.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_hdac_bus_add_device() and snd_hdac_remove_device() are called only
internally in hda-core. Let's drop the exports of them and move the
declarations into local.h.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The call of snd_hdac_bus_add_device() is needed only for registering
the codec onto the bus caddr_tbl[] that is referred essentially only
in the unsol event handler. That is, the reason of this call and the
release by the counter-part function snd_hdac_bus_remove_device() is
just to assure that the unsol event gets notified to the codec.
But the current implementation of the unsol notification wouldn't work
properly when the codec is still in a premature init state. So this
patch tries to work around it by delaying the caddr_tbl[] registration
at the point of snd_hdac_device_register().
Also, the order of snd_hdac_bus_remove_device() and device_del() calls
are shuffled to make sure that the unsol event is masked before
deleting the device.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204565
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently we set hdac_stream.fifo_size field only for the playback
stream by some odd reason I forgot, while this field isn't referred in
any places. Actually this fifo_size field would have been required in
the position report correction for VIA chipset, but due to the lack of
the fifo_size set for capture streams, snd-hda-intel driver fetches
the register by itself.
This patch straightens and simplifies the code by setting the
fifo_size field for both playback and capture streams, and use it in
the HD-audio controller driver.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
HD-audio drivers access to the mmio registers indirectly via the
corresponding bus->io_ops callbacks. This is because some platform
(notably Tegra SoC) requires the word-aligned access. But it's rather
a rare case, and other platforms suffer from the penalties by indirect
calls unnecessarily.
This patch is an attempt to optimize and cleanup for this situation.
Now the special aligned access is used only when a new kconfig
CONFIG_SND_HDA_ALIGNED_MMIO is set. And the HD-audio core itself
provides the aligned MMIO access helpers instead of the driver side.
If Kconfig isn't set (as default), the standard helpers like readl()
or writel() are used directly.
A couple of places in ASoC Intel drivers have the access via io_ops
reg_writel(), and they are replaced with the direct writel() calls.
And now with this patch, the whole bus->io_ops becomes empty, so it's
dropped completely. The bus initialization functions are changed
accordingly as well to drop the whole bus->io_ops.
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The HD-audio core allocates and releases pages via driver's specific
dma_alloc_pages and dma_free_pages ops defined in bus->io_ops. This
was because some platforms require the uncached pages and the handling
of page flags had to be done locally in the driver code.
Since the recent change in ALSA core memory allocator, we can simply
pass SNDRV_DMA_TYPE_DEV_UC for the uncached pages, and the only
difference became about this type to be passed to the core allocator.
That is, it's good time for cleaning up the mess.
This patch changes the allocation code in HD-audio core to call the
core allocator directly so that we get rid of dma_alloc_pages and
dma_free_pages io_ops. If a driver needs the uncached pages, it has
to set bus->dma_type right after the bus initialization.
This is merely a code refactoring and shouldn't bring any behavior
changes.
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The NHLT spec defines a VENDOR_DEFINED geometry, which requires
reading additional information to figure out the number of
microphones.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Move parts of the code outside of the Skylake driver to help detect
the presence of DMICs (which are not supported by the HDaudio legacy
driver).
No functionality change (except for the removal of useless OR
operations), only indentation and checkpatch fixes, making sure
that the code compiles without ACPI and fixing an ACPI leak
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Distribution installation images such as Debian include different sets
of modules which can be downloaded dynamically. Such images may notably
include the hda sound modules but not the i915 DRM module, even if the
latter was enabled at build time, as reported on
https://bugs.debian.org/931507
In such a case hdac_i915 would be linked in and try to load the i915
module, fail since it is not there, but still wait for a whole minute
before giving up binding with it.
This fixes such as case by only waiting for the binding if the module
was properly loaded (or module support is disabled, in which case i915
is already compiled-in anyway).
Fixes: f9b54e1961 ("ALSA: hda/i915: Allow delayed i915 audio component binding")
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a very big update, mainly thanks to Morimoto-san's refactoring
work and some fairly large new drivers.
- Lots more work on moving towards a component based framework from
Morimoto-san.
- Support for force disconnecting muxes from Jerome Brunet.
- New drivers for Cirrus Logic CS47L35, CS47L85 and CS47L90, Conexant
CX2072X, Realtek RT1011 and RT1308.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl0jGwUTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0LD4B/9AkutfS+vznOrk0V0wFb2SUfjwE4Pr
+z/kAehohAOl/7pg9Dun/lmZYBWMyOM2aYmK81ahEo2DfO+uzwkwjCaXFjGVGwEK
j7XpWkrIjKnou/z1FeALgVvt+crzdy5iNWC04AbKaP2WHCcI7zvPQIsBta/V0OJt
lg+j0J7pagnTMcgV1+qJdaASmofy/hpoZ79Gv0PIfGC8hpJ/3mBgcNPCLQrJtD4R
v+tzvCZNrZVqCanwLf3vouEm1bpWYOpI+Wdmu4u6rY7MhmCj72EJ2zyfdm/qtaxF
e7whgCyOQFkWe7NgDn0G08aAT6LsaxOtPNr7H8tL8S8sw8425fqeOouV
=n/HQ
-----END PGP SIGNATURE-----
Merge tag 'asoc-v5.3' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Updates for v5.3
This is a very big update, mainly thanks to Morimoto-san's refactoring
work and some fairly large new drivers.
- Lots more work on moving towards a component based framework from
Morimoto-san.
- Support for force disconnecting muxes from Jerome Brunet.
- New drivers for Cirrus Logic CS47L35, CS47L85 and CS47L90, Conexant
CX2072X, Realtek RT1011 and RT1308.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Along with the recent fix for the races of snd_hdac_refresh_widgets()
it turned out that the instantiation of widgets sysfs at
snd_hdac_sysfs_reinit() could cause a race. The race itself was
already covered later by extending the mutex protection range, the
commit 98482377dc ("ALSA: hda: Fix widget_mutex incomplete
protection"), but this also indicated that the call of *_reinit() is
basically superfluous, as the widgets shall be created sooner or later
from snd_hdac_device_register().
This patch removes the redundant call of snd_hdac_sysfs_reinit() at
first. By this removal, the sysfs argument itself in
snd_hdac_refresh_widgets() becomes superfluous, too, because the only
case sysfs=false is always with codec->widgets=NULL. So, we drop this
redundant argument as well.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The widget_mutex was introduced to serialize callers to
hda_widget_sysfs_{re}init. However, its protection of the sysfs widget array
is incomplete. For example, it is acquired around the call to
hda_widget_sysfs_reinit(), which actually creates the new array, but isn't
still acquired when codec->num_nodes and codec->start_nid is updated. So
the lock ensures one thread sets up the new array at a time, but doesn't
ensure which thread's value will end up in codec->num_nodes. If a larger
num_nodes wins but a smaller array was set up, the next call to
refresh_widgets() will touch free memory as it iterates over codec->num_nodes
that aren't there.
The widget_lock really protects both the tree as well as codec->num_nodes,
start_nid, and end_nid, so make sure it's held across that update. It should
also be held during snd_hdac_get_sub_nodes(), so that a very old read from that
function doesn't end up clobbering a later update.
Fixes: ed180abba7 ("ALSA: hda: Fix race between creating and refreshing sysfs entries")
Signed-off-by: Evan Green <evgreen@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This back-merge is necessary for adjusting the latest FireWire fix
with the recent refactoring in 5.3 development branch.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
To save power, the hda hdmi driver in ASoC invokes snd_hdac_ext_bus_link_put
to disable CORB/RIRB buffers DMA if there is no user of bus and invokes
snd_hdac_ext_bus_link_get to set up CORB/RIRB buffers when it is used.
Unsolicited responses is disabled in snd_hdac_bus_stop_cmd_io called by
snd_hdac_ext_bus_link_put , but it is not enabled in snd_hdac_bus_init_cmd_io
called by snd_hdac_ext_bus_link_get. So for put-get sequence, Unsolicited
responses is disabled and headphone can't be detected by hda codecs.
Now unsolicited responses is only enabled in snd_hdac_bus_reset_link
which resets controller. The function is only called for setup of
controller. This patch enables Unsolicited responses after RIRB is
initialized in snd_hdac_bus_init_cmd_io which works together with
snd_hdac_bus_reset_link to set up controller.
Tested legacy hda driver and SOF driver on intel whiskeylake.
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Rander Wang <rander.wang@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
