When a new timer instance is created and assigned to the active link
in snd_timer_open(), the caller still doesn't (can't) set its callback
and callback data. In both the user-timer and the sequencer-timer
code, they do manually set up the callbacks after calling
snd_timer_open(). This has a potential risk of race when the timer
instance is added to the already running timer target, as the callback
might get triggered during setting up the callback itself.
This patch tries to address it by changing the API usage slightly:
- An empty timer instance is created at first via the new function
snd_timer_instance_new(). This object isn't linked to the timer
list yet.
- The caller sets up the callbacks and others stuff for the new timer
instance.
- The caller invokes snd_timer_open() with this instance, so that it's
linked to the target timer.
For closing, do similarly:
- Call snd_timer_close(). This unlinks the timer instance from the
timer list.
- Free the timer instance via snd_timer_instance_free() after that.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20191107192008.32331-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The code in both snd_timer_check_master() and snd_timer_check_slave()
are almost identical, both check whether the master/slave link and
does linkage. Factor out the common code and call it from both
functions for readability.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20191107192008.32331-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some big changes in the core but more about cleanps and refactorings
than new features, plus a collection of new drivers and lots of small
fixes and improvements to existing ones.
- Lots more cleanups from Morimoto-san. Now that everything is a
component this is mostly about refactorings to clarify and simplify
the core, a combination of things that are no longer required due to
refactorings and spotting similarities.
- Many fixes to the Sound Open Firmware code.
- Wake on voice support for Chromebooks.
- SPI support for RT5677.
- New drivers for Analog Devices ADAU7118, Intel Cannonlake systems
with RT1011 and RT5682, Texas Instruments TAS2562 and TAS2770.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl3EFLYTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0JCuB/40P/KPRGlEFBSJAwTfCkjQxzvQUGBy
Y3w9QeMq3ONhCJt5BusmeuFqdkanzYqnl+NveGYKdKNTAwh6vEMGiMbGSB8dgrR5
R7PLNBDRJi7ZUDdOZle7VrdUiZWyieaZk/ecWxfTPKfqzoBjnM3XYSa30i55hvbQ
A2MTimFsO7nf0caLNBLqEqBjy68IHQ3tuHH27kA0MIpVNsYVrjaWfM400ot3odbg
0vMpNTM+PDcQGkWcq3sKJBOVVjmGg2Xs1yM5hv6Mu+q1zXLCtCKj+Pv+ZXC3BT6e
Yyxv/arpgvtjIU79Tv9RamVRC4jN6ZJRkThP9UW6JrX7tPCjvD+ygzPn
=4FMp
-----END PGP SIGNATURE-----
Merge tag 'asoc-v5.5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next
ASoC: Updates for v5.5
Some big changes in the core but more about cleanps and refactorings
than new features, plus a collection of new drivers and lots of small
fixes and improvements to existing ones.
- Lots more cleanups from Morimoto-san. Now that everything is a
component this is mostly about refactorings to clarify and simplify
the core, a combination of things that are no longer required due to
refactorings and spotting similarities.
- Many fixes to the Sound Open Firmware code.
- Wake on voice support for Chromebooks.
- SPI support for RT5677.
- New drivers for Analog Devices ADAU7118, Intel Cannonlake systems
with RT1011 and RT5682, Texas Instruments TAS2562 and TAS2770.
These are a collection of fixes since v5.4-rc4 that have accumilated,
they're all driver specific and there's nothing major in here so it's
probably not essential to actually send them but I'll leave that call to
you.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl3EETsTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0BJCB/968YQYuvmvJbBify4l+l56rz3O0Qge
/dkifAsiBLYctwjYKVaqPhrcLts6gaKSZnKwNjF1d5ucjwb9y2cTuJoh65xJw4Z6
wgOBJiVC0wTdLzLMStVAX6QKFP6oVgWkKuaWRfhWiCbdWMVQesQlZePmu/PYU2IH
/B60aTN4noSMycFqmdHfyVGXnTX7cONCFr9cfE/EX+uQLCFe+QD7UItCEGl/1uwp
84mfNdLFkhX72yEEb5SZvGac5k9fyRvy1TPqkO5r+BQeYnePUMCpuA2mZaO9yBUh
r+6AMDcF300lXt860UtBidugpC5YM9vNUAu/dXMDowP8A+vBg2aquYe+
=GWKb
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v5.4-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v5.4
These are a collection of fixes since v5.4-rc4 that have accumilated,
they're all driver specific and there's nothing major in here so it's
probably not essential to actually send them but I'll leave that call to
you.
When using the example SOF amp widget topology, KASAN dumps this
when the AMP bytes kcontrol gets loaded:
[ 9.579548] BUG: KASAN: slab-out-of-bounds in
sof_control_load+0x8cc/0xac0 [snd_sof]
[ 9.588194] Write of size 40 at addr ffff8882314559dc by task
systemd-udevd/2411
Fix that by rejecting the topology if the bytes data size > max_size
Fixes: 311ce4fe76 ("ASoC: SOF: Add support for loading topologies")
Reviewed-by: Jaska Uimonen <jaska.uimonen@intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Dragos Tarcatu <dragos_tarcatu@mentor.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191106145816.9367-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The clean up commit 41672c0c24 ("ALSA: timer: Simplify error path in
snd_timer_open()") unified the error handling code paths with the
standard goto, but it introduced a subtle bug: the timer instance is
stored in snd_timer_open() incorrectly even if it returns an error.
This may eventually lead to UAF, as spotted by fuzzer.
The culprit is the snd_timer_open() code checks the
SNDRV_TIMER_IFLG_EXCLUSIVE flag with the common variable timeri.
This variable is supposed to be the newly created instance, but we
(ab-)used it for a temporary check before the actual creation of a
timer instance. After that point, there is another check for the max
number of instances, and it bails out if over the threshold. Before
the refactoring above, it worked fine because the code returned
directly from that point. After the refactoring, however, it jumps to
the unified error path that stores the timeri variable in return --
even if it returns an error. Unfortunately this stored value is kept
in the caller side (snd_timer_user_tselect()) in tu->timeri. This
causes inconsistency later, as if the timer was successfully
assigned.
In this patch, we fix it by not re-using timeri variable but a
temporary variable for testing the exclusive connection, so timeri
remains NULL at that point.
Fixes: 41672c0c24 ("ALSA: timer: Simplify error path in snd_timer_open()")
Reported-and-tested-by: Tristan Madani <tristmd@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191106165547.23518-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The fuzzer tries to open the timer instances as much as possible, and
this may cause a system hiccup easily. We've already introduced the
cap for the max number of available instances for the h/w timers, and
we should put such a limit also to the slave timers, too.
This patch introduces the limit to the multiple opened slave timers.
The upper limit is hard-coded to 1000 for now, which should suffice
for any practical usages up to now.
Link: https://lore.kernel.org/r/20191106154257.5853-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_soc_unregister_component() is calling snd_soc_lookup_component()
under mutex_lock(). But, snd_soc_lookup_component() itself is using
mutex_lock(), thus it will be dead-lock.
This patch adds _nolocked version of it, and avoid dead-lock issue.
Fixes: ac6a4dd3e9f0("ASoC: soc-core: use snd_soc_lookup_component() at snd_soc_unregister_component()")
Reported-by: "kernelci.org bot" <bot@kernelci.org>"
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87bltph4da.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
SOF module load/unload tests show nasty recurring warnings:
WARNING: CPU: 5 PID: 1339 at sound/core/control.c:466
snd_ctl_remove+0xf0/0x100 [snd]
RIP: 0010:snd_ctl_remove+0xf0/0x100 [snd]
This regression was introduced by the removal of the call to
soc_remove_link_components() before soc_card_free() is invoked.
Go back to the initial order but only call
soc_remove_link_components() once.
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Fixes: 5a4c9f054c ("ASoC: soc-core: snd_soc_unbind_card() cleanup")
GitHub issue: https://github.com/thesofproject/linux/issues/1424
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191106145801.9316-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When using the example SOF amp widget topology, KASAN dumps this
when the AMP bytes kcontrol gets loaded:
[ 9.579548] BUG: KASAN: slab-out-of-bounds in
sof_control_load+0x8cc/0xac0 [snd_sof]
[ 9.588194] Write of size 40 at addr ffff8882314559dc by task
systemd-udevd/2411
Fix that by rejecting the topology if the bytes data size > max_size
Fixes: 311ce4fe76 ("ASoC: SOF: Add support for loading topologies")
Reviewed-by: Jaska Uimonen <jaska.uimonen@intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Dragos Tarcatu <dragos_tarcatu@mentor.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191106145816.9367-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pass the device pointer from the PCI pointer directly, instead of a
non-standard macro. The macro didn't give any better readability.
Along with it, drop the unnecessary assignment before the
snd_dma_alloc_pages() call and simplify by returning the error code
directly.
Link: https://lore.kernel.org/r/20191105151856.10785-23-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Pass the device pointer from the PCI pointer directly, instead of a
non-standard macro. The macro didn't give any better readability.
Along with it, the unneeded assignment before snd_dma_alloc_pages*()
call is dropped.
Link: https://lore.kernel.org/r/20191105151856.10785-22-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Pass the device pointer from the PCI pointer directly, instead of a
non-standard macro. The macro didn't give any better readability.
Also slightly refactor the code (drop the return value check from the
preallocation) as it never returns an error.
Link: https://lore.kernel.org/r/20191105151856.10785-21-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_pcm_sgbuf_ops_page is no longer needed to be set explicitly to PCM
page ops since the recent change in the PCM core (*). Leaving it NULL
should work as long as the preallocation has been done properly.
This patch drops the redundant lines.
(*) 7e8edae39f: ALSA: pcm: Handle special page mapping in the
default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-19-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cf: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39f: ALSA: pcm: Handle special page mapping in the
default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-18-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cf: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39f: ALSA: pcm: Handle special page mapping in the
default mmap handler
Since the driver requires the DMA32 allocation, it passes the
specially encoded device to snd_pcm_lib_preallocate_pages().
Link: https://lore.kernel.org/r/20191105151856.10785-17-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cf: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39f: ALSA: pcm: Handle special page mapping in the
default mmap handler
Since the driver requires the DMA32 allocation, it passes the
specially encoded device to snd_pcm_lib_preallocate_pages().
Link: https://lore.kernel.org/r/20191105151856.10785-16-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cf: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39f: ALSA: pcm: Handle special page mapping in the
default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-15-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cf: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39f: ALSA: pcm: Handle special page mapping in the
default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-14-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cf: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39f: ALSA: pcm: Handle special page mapping in the
default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-13-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cf: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39f: ALSA: pcm: Handle special page mapping in the
default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-12-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cf: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39f: ALSA: pcm: Handle special page mapping in the
default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-11-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cf: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39f: ALSA: pcm: Handle special page
mapping in the default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-10-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cf: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39f: ALSA: pcm: Handle special page mapping in the
default mmap handler
Also, since the SG-buffer-specific PCM ops becomes identical with the
normal PCM ops, unify them again to the single ops, too.
Link: https://lore.kernel.org/r/20191105151856.10785-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (commit 08422d2c55: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.
Link: https://lore.kernel.org/r/20191105151856.10785-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (commit 08422d2c55: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.
Link: https://lore.kernel.org/r/20191105151856.10785-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (commit 08422d2c55: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.
Link: https://lore.kernel.org/r/20191105151856.10785-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (commit 08422d2c55: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.
Link: https://lore.kernel.org/r/20191105151856.10785-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (commit 08422d2c55: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.
Link: https://lore.kernel.org/r/20191105151856.10785-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (commit 08422d2c55: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.
Link: https://lore.kernel.org/r/20191105151856.10785-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It makes little sense to create prealloc proc files for streams that
have the zero max size, which is a typical case for vmalloc buffers.
Skip the proc file creations to save resources in such a case.
Link: https://lore.kernel.org/r/20191105191007.18150-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Warn if snd_pcm_lib_preallocate_pages*() is applied to the stream that
has already the preallocated buffers and skip the allocation. It's a
clearly a driver bug.
Link: https://lore.kernel.org/r/20191105191007.18150-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When a driver needs to deal with a special buffer like a SG or a
vmalloc buffer, it has to set up the PCM page ops explicitly for the
corresponding helper function. This is rather error-prone and many
people forgot or incorrectly used it.
For simplifying the call patterns and avoiding such a potential bug,
this patch enhances the PCM default mmap handler to check the
(pre-)allocated buffer type and handles the page gracefully depending
on the buffer type. If the PCM page ops is given, the ops is still
used in a higher priority. The new code path is only for the default
(NULL page ops) case.
Link: https://lore.kernel.org/r/20191105080138.1260-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch adds the vmalloc buffer support to ALSA memalloc core. A
new type, SNDRV_DMA_TYPE_VMALLOC was added.
The vmalloc buffer has been already supported in the PCM via a few own
helper functions, but the user sometimes get confused and misuse
them. With this patch, the whole buffer management is integrated into
the memalloc core, so they can be used in a sole common way.
Link: https://lore.kernel.org/r/20191105080138.1260-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently we pass the artificial device pointer to the allocation
helper in the case of SNDRV_DMA_TYPE_CONTINUOUS for passing the GFP
flags. But all common cases are the allocations with GFP_KERNEL, and
it's messy to put this in each place.
In this patch, the memalloc core helper is changed to accept the NULL
device pointer and it treats as the default mode, GFP_KERNEL, so that
all callers can omit the complex argument but just leave NULL.
Link: https://lore.kernel.org/r/20191105080138.1260-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
soc-core has some API which is used from topology, but it is doing
topology specific operation at soc-core.
soc-core should care about core things, and topology should care
about topology things, otherwise, it is very confusable.
For example topology type is not related to soc-core,
it is topology side issue.
This patch removes meaningless check from soc-core.
This patch keeps extra initialization/destruction at
snd_soc_add_dai_link() / snd_soc_remove_dai_link()
which were for topology.
From this patch, non-topology card can use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87pni6251h.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ALSA SoC has 2 functions.
snd_soc_register_dai() is used from topology
snd_soc_register_dais() is used from snd_soc_add_component()
In general, people think like _dai() is called from _dais()
with for loop. But in reality, these are very similar
but different implementation.
We shouldn't have duplicated and confusing implementation.
This patch calls snd_soc_register_dai() from snd_soc_register_dais()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87r22m251l.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ALSA SoC has 2 functions.
snd_soc_register_dai() is used from topology
snd_soc_register_dais() is used from snd_soc_add_component()
In general, people think like _dai() is called from _dais()
with for loop. But in reality, these are very similar
but different implementation.
We shouldn't have duplicated and confusing implementation.
snd_soc_register_dai() is now used from topology.
But to reduce duplicated code, it should be used from _dais(), too.
Because of topology side specific reason,
it is calling snd_soc_dapm_new_dai_widgets(),
but it is not needed _dais() side.
This patch factorizes snd_soc_register_dai() to
topology / _dais() common part, and topology specific part.
And do topology specific part at soc-topology.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87sgn2251p.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ALSA SoC has 2 functions.
snd_soc_register_dai() is used from topology
snd_soc_register_dais() is used from snd_soc_add_component()
In general, people think like _dai() is called from _dais()
with for loop. But in reality, these are very similar
but different implementation.
We shouldn't have duplicated and confusing implementation.
snd_soc_register_dai() is now used from topology.
But to reduce duplicated code, it should be used from _dais(), too.
To prepare it, this patch adds missing parameter legacy_dai_naming
to snd_soc_register_dai().
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87tv7i251u.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
It is easy to read code if it is cleanly using paired function/naming,
like start <-> stop, register <-> unregister, etc, etc.
But, current ALSA SoC code is very random, unbalance, not paired, etc.
It is easy to create bug at the such code, and is difficult to debug.
This patch adds missing soc_del_dai() and snd_soc_unregister_dai().
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87v9ry251z.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch moves snd_soc_unregister_dais() next to
snd_soc_register_dais().
This is prepare for snd_soc_register_dais() cleanup
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87woce2524.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch moves snd_soc_register_dai() next to
snd_soc_register_dais().
This is prepare for snd_soc_register_dais() cleanup.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87y2wu2528.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
snd_soc_unregister_component() is now finding component manually,
but we already have snd_soc_lookup_component() to find component;
Let's use existing function.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87zhha252c.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
soc-core has
snd_soc_add_component(), snd_soc_component_add(),
snd_soc_del_component(), snd_soc_component_del().
These are very confusing naming.
snd_soc_component_xxx() are called from snd_soc_xxx_component(),
and these are very small.
Let's merge these into snd_soc_xxx_component(), and
remove snd_soc_component_xxx().
Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/871rum3jmy.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
It is easy to read code if it is cleanly using paired function/naming,
like start <-> stop, register <-> unregister, etc, etc.
But, current ALSA SoC code is very random, unbalance, not paired, etc.
It is easy to create bug at the such code, and is difficult to debug.
Now ALSA SoC has snd_soc_add_component(), but there is no paired
snd_soc_del_component(). Thus, snd_soc_unregister_component() is
calling cleanup function randomly. it is difficult to read.
This patch adds missing snd_soc_del_component_unlocked() and
balance up code.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/8736f23jn4.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
snd_soc_lookup_component() is using mix of continue and break
in the same loop. It is odd.
This patch cleanup it.
Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/874kzi3jn8.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch moves snd_soc_lookup_component() to upper side.
This is prepare for snd_soc_unregister_component()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/875zjy3jnd.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
It is easy to read code if it is cleanly using paired function/naming,
like start <-> stop, register <-> unregister, etc, etc.
But, current ALSA SoC code is very random, unbalance, not paired, etc.
It is easy to create bug at the such code, and it will be difficult to
debug.
ALSA SoC has soc_bind_dai_link(), but its paired soc_unbind_dai_link()
is not implemented.
More confusable is that soc_remove_pcm_runtimes() which should be
soc_unbind_dai_link() is implemented without synchronised
to soc_bind_dai_link().
This patch cleanup this unbalance.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/877e4e3jni.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If we focus to soc_bind_dai_link() at snd_soc_instantiate_card(),
we will notice very complex operation.
static int snd_soc_instantiate_card(...)
{
...
/*
* (1) Bind dai_link via card pre-linked dai_link
*
* Bind dai_link via card pre-linked.
* 1 dai_link will be 1 rtd, and connected to card.
* for_each_card_prelinks() is for card pre-linked dai_link.
*
* Image
*
* card
* - rtd(A)
* - rtd(A)
*/
for_each_card_prelinks(card, i, dai_link) {
ret = soc_bind_dai_link(card, dai_link);
...
}
...
/*
* (2) Connect card pre-linked dai_link to card list
*
* Connect all card pre-linked dai_link to *card list*.
* Here, (A) means from card pre-linked.
*
* Image
*
* card card list
* - rtd(A) - dai_link(A)
* - rtd(A) - dai_link(A)
* - ... - ...
*/
for_each_card_prelinks(card, i, dai_link) {
ret = snd_soc_add_dai_link(card, dai_link);
...
}
...
/*
* (3) Probe binded component
*
* Each rtd has many components.
* Here probes each rtd connected components.
* rtd(A) in Image is the probe target.
*
* During this component probe, topology may add new dai_link to
* *card list* by using snd_soc_add_dai_link() which is
* used at (2).
* Here, (B) means from topology
*
* Image
*
* card card list
* - rtd(A) - dai_link(A)
* - rtd(A) - dai_link(A)
* - ... - ...
* - dai_link(B)
* - dai_link(B)
*/
ret = soc_probe_link_components(card);
...
/*
* (4) Bind dai_link again
*
* Bind dai_link again for topology.
* Note, (1) used for_each_card_prelinks(),
* here is using for_each_card_links()
*
* This means from card list.
* As Image indicating, it has dai_link(A) (from card pre-link)
* and dai_link(B) (from topology).
* main target here is dai_link(B).
* soc_bind_dai_link() ignores already used
* dai_link (= dai_link(A))
*
* Image
*
* card card list
* - rtd(A) - dai_link(A)
* - rtd(A) - dai_link(A)
* - ... - ...
* - rtd(B) - dai_link(B)
* - rtd(B) - dai_link(B)
*/
for_each_card_links(card, dai_link) {
ret = soc_bind_dai_link(card, dai_link);
...
}
...
}
As you see above, it is doing very complex method.
The problem is binding dai_link via "card pre-linked" (= (1)) and
"topology added dai_link" (= (3)) are separated.
The code can be simple if we can bind dai_link when dai_link
is connected to *card list*.
This patch do it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/878sou3jnn.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
soc_is_dai_link_bound() check will be called both
*before* soc_bind_dai_link() (A), and
*under* soc_bind_dai_link() (B).
These are very verbose code. Let's remove one of them.
* static int soc_bind_dai_link(...)
{
...
(B) if (soc_is_dai_link_bound(...)) {
...
return 0;
}
...
}
static int snd_soc_instantiate_card(...)
{
...
for_each_card_links(...) {
(A) if (soc_is_dai_link_bound(...))
continue;
* ret = soc_bind_dai_link(...);
if (ret)
goto probe_end;
}
...
}
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87a79a3jns.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
soc_init_dai_link() is needed to be called before soc_bind_dai_link().
int snd_soc_instantiate_card()
{
for_each_card_prelinks(...) {
(1) ret = soc_init_dai_link(...);
...
}
...
for_each_card_prelinks(...) {
(2) ret = soc_bind_dai_link(...);
...
}
...
for_each_card_links(...) {
...
(A) ret = soc_init_dai_link(...);
...
(B) ret = soc_bind_dai_link(...);
}
...
(1) is for (2), and (A) is for (B)
(1) and (2) are for card prelink dai_link.
(A) and (B) are for topology added dai_link.
soc_init_dai_link() is sanity check for dai_link, not initializing today.
Therefore, it is confusable naming. We can rename it as sanity_check.
And this check is for soc_bind_dai_link().
It can be more simple code if we can call it from soc_bind_dai_link().
This patch renames it to soc_dai_link_sanity_check(), and
call it from soc_bind_dai_link().
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87d0e63joh.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch moves soc_init_dai_link() next to soc_bind_dai_link().
This is prepare for soc_bind_dai_link() cleanup.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87eeym3joq.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Set trigger order for FE DAI links to SND_SOC_DPCM_TRIGGER_POST
to trigger the BE DAI's before the FE DAI's. This prevents the
xruns seen on playback pipelines using the link DMA.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191104224812.3393-3-ranjani.sridharan@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, the trigger orders SND_SOC_DPCM_TRIGGER_PRE/POST
determine the order in which FE DAI and BE DAI are triggered.
In the case of SND_SOC_DPCM_TRIGGER_PRE, the FE DAI is
triggered before the BE DAI and in the case of
SND_SOC_DPCM_TRIGGER_POST, the BE DAI is triggered before
the FE DAI. And this order remains the same irrespective of the
trigger command.
In the case of the SOF driver, during playback, the FW
expects the BE DAI to be triggered before the FE DAI during
the START trigger. The BE DAI trigger handles the starting of
Link DMA and so it must be started before the FE DAI is started
to prevent xruns during pause/release. This can be addressed
by setting the trigger order for the FE dai link to
SND_SOC_DPCM_TRIGGER_POST. But during the STOP trigger,
the FW expects the FE DAI to be triggered before the BE DAI.
Retaining the same order during the START and STOP commands,
results in FW error as the DAI component in the FW is still
active.
The issue can be fixed by mirroring the trigger order of
FE and BE DAI's during the START and STOP trigger. So, with the
trigger order set to SND_SOC_DPCM_TRIGGER_PRE, the FE DAI will be
trigger first during SNDRV_PCM_TRIGGER_START/STOP/RESUME
and the BE DAI will be triggered first during the
STOP/SUSPEND/PAUSE commands. Conversely, with the trigger order
set to SND_SOC_DPCM_TRIGGER_POST, the BE DAI will be triggered
first during the SNDRV_PCM_TRIGGER_START/STOP/RESUME commands
and the FE DAI will be triggered first during the
SNDRV_PCM_TRIGGER_STOP/SUSPEND/PAUSE commands.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191104224812.3393-2-ranjani.sridharan@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Do not support mmap in S/PDIF mode. In S/PDIF mode
the buffer has to be copied, to allow the channel status
bits insertion.
Signed-off-by: Olivier Moysan <olivier.moysan@st.com>
Link: https://lore.kernel.org/r/20191104133654.28750-1-olivier.moysan@st.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The unsolicited event handler for the headphone jack on CA0132 codec
driver tries to reschedule the another delayed work with
cancel_delayed_work_sync(). It's no good idea, unfortunately,
especially after we changed the work queue to the standard global
one; this may lead to a stall because both works are using the same
global queue.
Fix it by dropping the _sync but does call cancel_delayed_work()
instead.
Fixes: 993884f6a2 ("ALSA: hda/ca0132 - Delay HP amp turnon.")
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1155836
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191105134316.19294-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 same driver is reused for 3 different configurations, but the
driver will only be build if ApolloLake is selected.
Fix and make sure each device can work without dependencies on others
(useful for minimal configurations).
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101173045.27099-10-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This option is only required with the Skylake platform driver, there
is no reason to have this option in machine drivers. This is
e.g. useless for SOF-based solutions.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101173045.27099-9-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This option famously broke audio on Linus' laptop and the problem have
not been fixed.
Mark as DEPRECATED to avoid any ambiguity with distros.
Use SOF if you need HDaudio support w/ the DSP enabled, e.g. for DMIC
capture.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101173045.27099-8-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
So far we used select to use the relevant built-in/module options, but
this led to blurring layers between core and Intel Kconfigs.
Use def_tristate works just as well and removes Intel stuff from the code.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101173045.27099-7-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
updated solution to the problem reported with randconfig:
CONFIG_SND_SOC_SOF_IMX depends on CONFIG_SND_SOC_SOF, but is in
turn referenced by the sof-of-dev driver. This creates a reverse
dependency that manifests in a link error when CONFIG_SND_SOC_SOF_OF
is built-in but CONFIG_SND_SOC_SOF_IMX=m:
sound/soc/sof/sof-of-dev.o:(.data+0x118): undefined reference to `sof_imx8_ops'
use def_trisate to propagate the right settings without select.
Fixes: f4df4e4042 ("ASoC: SOF: imx8: Fix COMPILE_TEST error")
Fixes: 202acc565a ("ASoC: SOF: imx: Add i.MX8 HW support")
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101173045.27099-6-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some distros select all possible options, despite existing warnings to
be careful. This leads to e.g. user reports that the HDaudio codec and
DMIC are not handled by SOF.
Add an explicit menu item to unlock developer options, and make them
dependent on CONFIG_EXPERT. Hopefully with this double-lock these
options will only be selected by developers.
GitHub issue: https://github.com/thesofproject/sof/issues/1885
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101173045.27099-5-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some distros select all options blindly, which leads to confusion and
bug reports. SOF does not fully support Broadwell due to firmware
dependencies, the machine drivers can only support one option, and
UCM/topology files are still being propagated to downstream distros,
so make SOF on Broadwell an opt-in option that first require distros
to opt-out of existing defaults.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204237
Fixes: f35bf70f61 ('ASoC: Intel: Make sure BDW based machine drivers build for SOF')
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101173045.27099-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some distros select all options blindly, which leads to confusion and
bug reports. Since SOF does not support Baytrail-CR for now, and
UCM/topology files are still being propagated to downstream distros,
make SOF on Baytrail an opt-in option that first require distros to
opt-out of existing defaults.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101173045.27099-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove the retry argument for the hda_dsp_wait_d0i3c_done()
function and use the HDA_DSP_REG_POLL_RETRY_COUNT macro
directly.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101170916.26517-4-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Machine driver to enable
RT5682 on SSP0, DMIC, HDMI and
RT1011 AMP on SSP1 with
2 CH / 24 bit TDM Playback over 4 individual codecs and
4 CH / 24 bit Capture to provide feedback.
Signed-off-by: Naveen Manohar <naveen.m@intel.com>
Signed-off-by: Sathya Prakash M R <sathya.prakash.m.r@intel.com>
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/20191101171847.26767-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add match for CML m/c with RT1011 and RT5682
Signed-off-by: Naveen Manohar <naveen.m@intel.com>
Signed-off-by: Sathya Prakash M R <sathya.prakash.m.r@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191101171847.26767-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When ASoC card instance is removed containing a HDA codec,
hdac_hda_codec_remove() may run in parallel with codec resume.
This will cause problems if the HDA link is freed with
snd_hdac_ext_bus_link_put() while the codec is still in
middle of its resume process.
To fix this, change the order such that pm_runtime_disable()
is called before the link is freed. This will ensure any
pending runtime PM action is completed before proceeding
to free the link.
This issue can be easily hit with e.g. SOF driver by loading and
unloading the drivers.
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/20191101170635.26389-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The check for the mmap support via hw_support_mmap() function misses
the case where the device is with SNDRV_DMA_TYPE_DEV_UC, which should
have been treated equally as SNDRV_DMA_TYPE_DEV. Let's fix it.
Note that this bug doesn't hit any practical problem, because
SNDRV_DMA_TYPE_DEV_UC is used only for x86-specific drivers
(snd-hda-intel and snd-intel8x0) for the specific platforms that need
the non-cached buffers. And, on such platforms, hw_support_mmap()
already returns true in anyway. That's the reason I didn't put
Cc-to-stable mark here. This is only for any theoretical future
extension.
Fixes: 425da15970 ("ALSA: pcm: use dma_can_mmap() to check if a device supports dma_mmap_*")
Fixes: 42e748a0b3 ("ALSA: memalloc: Add non-cached buffer type")
Link: https://lore.kernel.org/r/20191104101115.27311-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For Focusrite Saffire Pro i/o, the lowest 8 bits of register represents
configured source of sampling clock. The next lowest 8 bits represents
whether the configured source is actually detected or not just after
the register is changed for the source.
Current implementation evaluates whole the register to detect configured
source. This results in failure due to the next lowest 8 bits when the
source is connected in advance.
This commit fixes the bug.
Fixes: 25784ec2d0 ("ALSA: bebob: Add support for Focusrite Saffire/SaffirePro series")
Cc: <stable@vger.kernel.org> # v3.16+
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191102150920.20367-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Originally BeBeB ASICs and firmware supports clock mode to synchronizing
to syt field of received isoc packet. This mode is known as 'SYT Match'
slightly described in IEC 61883-6 (but no detail mechanisms). In this
mode, drivers can control sampling clock in device. Driver for Windows
and macOS uses this feature to perform synchronization for devices
on the same bus.
In this mode, a plug of Music subunit for synchronization is connected
to a plug of isoc unit for incoming packet streaming, then the order to
establish connections is INPUT_PLUG first, OUTPUT_PLUG second.
This commit implements the above.
Actually each device works with its own clock for sampling, therefore
the original design is hardly implemented to vendor's products.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191101131323.17300-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As long as I investigated, there's some cases about the delay for device
between establishing OUTPUT_PLUG and transmitting first isoc packet. For
devices which support BeBoB protocol version 1 can transmit the packet
within several hundred milliseconds, while for devices which support
BeBoB protocol version 3 can transmit the packet within 2 seconds.
Devices with protocol version 1:
* Edirol FA-66
* Yamaha GO46
* Terratec Phase x24 FW
* M-Audio FireWire AudioPhile
* M-Audio FireWire Solo
* M-Audio FireWire 1814
* M-Audio FireWire 410
* Focusrite Saffire Pro 26 I/O
Devices with protocol version 3:
* M-Audio Profire Lightbridge
* Behringer FCA610
* Phonic Firefly 202
At present ALSA bebob driver postpones starting IR context during
1.5 sec for all of supported devices. The delay is too long for
devices with protocol version 1, while it's not enough for devices with
protocol version 3.
This commit improves the delay for these protocols.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191101131323.17300-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As long as I investigated, some devices with BeBoB protocol version 1
can be freezed during several hundreds milliseconds after breaking
connections. When accessing during the freezed time, any transaction
is corrupted. In the worst case, the device is going to reboot.
I can see this issue in:
* Roland FA-66
* M-Audio FireWire Solo
This commit expands sleep just after breaking connections to avoid
the freezed time as much as possible. I note that the freeze/reboot
behaviour is similar to below models:
* Focusrite Saffire Pro 10 I/O
* Focusrite Saffire Pro 26 I/O
The above models certainly reboot after breaking connections.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191101131323.17300-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
There is no other code use the RT1011_INIT_REG_LEN definition,
except rt1011_reg_init().
Hence, we remove it and fix the typo.
Signed-off-by: Shuming Fan <shumingf@realtek.com>
Link: https://lore.kernel.org/r/20191031115446.21108-1-shumingf@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The !component->card->instantiated statement should remove in kcontrol.
It is no need to check the card->instantiated in kcontrol.
Signed-off-by: Shuming Fan <shumingf@realtek.com>
Link: https://lore.kernel.org/r/20191031115401.20898-1-shumingf@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When a card is disconnected while in use, the system waits until all
opened files are closed then releases the card. This is done via
put_device() of the card device in each device release code.
The recently reported mutex deadlock bug happens in this code path;
snd_timer_close() for the timer device deals with the global
register_mutex and it calls put_device() there. When this timer
device is the last one, the card gets freed and it eventually calls
snd_timer_free(), which has again the protection with the global
register_mutex -- boom.
Basically put_device() call itself is race-free, so a relative simple
workaround is to move this put_device() call out of the mutex. For
achieving that, in this patch, snd_timer_close_locked() got a new
argument to store the card device pointer in return, and each caller
invokes put_device() with the returned object after the mutex unlock.
Reported-and-tested-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The commit ade49db337 ("ALSA: hda/hdmi - Allow audio component for
AMD/ATI and Nvidia HDMI") introduced the spec->pcm_lock mutex lock to
the whole generic_hdmi_init() function for avoiding the race with the
audio component registration. However, this caused a dead lock when
the unsolicited event is handled without the audio component, as the
codec gets runtime-resumed in hdmi_present_sense() which is already
inside the spec->pcm_lock in its caller.
For avoiding this deadlock, add a new mutex only for the audio
component binding that is used in both generic_hdmi_init() and the
audio notifier registration where the jack callbacks are handled /
re-registered.
Fixes: ade49db337 ("ALSA: hda/hdmi - Allow audio component for AMD/ATI and Nvidia HDMI")
Reported-and-tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/s5himo7i89i.wl-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The sensitivity could improve by decreasing the HW debounce time
and reduce the delay time of workequeue.
This patch added a device property for HW debounce time control.
We could change this value to tune the sensitivity of push button.
Signed-off-by: Shuming Fan <shumingf@realtek.com>
Link: https://lore.kernel.org/r/20191030085533.14299-1-shumingf@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
snd_soc_tplg_component_remove() is pair of snd_soc_tplg_component_load(),
and it is topology related cleanup function.
The driver which called _load() needs to call _remove() by its responsibility.
Today, skl-pcm and topology are the user, and these are calling both
_load() and _remove().
soc-core doesn't need to call it.
This patch remove it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/8736fbdnwt.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch fixup this warning
LINUX/sound/soc/codecs/rt5677-spi.c: In function ‘rt5677_spi_pcm_close’:
LINUX/sound/soc/codecs/rt5677-spi.c:114:30: warning: unused variable ‘rtd’ [-Wunused-variable]
struct snd_soc_pcm_runtime *rtd = substream->private_data;
^~~
Fixes: a0e0d13542 ("ASoC: rt5677: Add a PCM device for streaming hotword via SPI")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87a79idajh.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Just fix a typo of "S/PDIF" in the clock name string.
Fixes: 4638ec6ede ("ALSA: firewire-motu: add proc node to show current statuc of clock and packet formats")
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191030100921.3826-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In MOTU FireWire series, devices which support protocol version 2 have
several types of hardware design to process audio data frames for isoc
packet. Roughly devices are categorized into three groups:
- 828mkII
- Traveler/896HD
- UltraLite/8pre FireWire
Some bit flags in register addressed by 0x'ffff'f000'0b14
includes device-specific effects.
This commit cleanups implementation of protocol v2 in this point.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191030080644.1704-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
