This reverts commit c82dbcbec1.
Reason for revert: use vendor_hook approach instead of adding a new field.
Change-Id: I001dafc1b90cfe4567a13f538c2f8d25a0929504
Signed-off-by: Bicycle Tsai <bicycle.tsai@mediatek.corp-partner.google.com>
dpcm_end_walk_at_be() stops the graph walk when first BE is found for
the given FE component. In a component model we may want to connect
multiple DAIs from different components. A new flag is introduced in
'snd_soc_card', which when set allows DAI/component chaining. Later
PCM operations can be called for all these listed components for a
valid DAPM path.
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Link:
https://lore.kernel.org/r/1604329814-24779-3-git-send-email-spujar@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 198732156
(cherry picked from commit aa293777bfeb75fb8872565ef99cc0e8b98b5c7d)
[ refactored to avoid breaking KMI ]
ALSA machine driver can setup component_chaining like below code slice.
static int my_board_late_probe(struct snd_soc_card *card)
{
struct snd_soc_card_ext *card_ext =
container_of(card, struct snd_soc_card_ext, card);
card_ext->component_chaining = 1;
return 0;
}
static struct snd_soc_card my_board_card = {
.name = MY_BOARD_NAME,
.owner = THIS_MODULE,
.dai_link = my_board_dai_links,
.num_links = ARRAY_SIZE(my_board_dai_links),
.late_probe = my_board_late_probe,
};
Change-Id: Icc9e9b120e721a620f7c9f49515342422f80edb7
Signed-off-by: Bicycle Tsai <bicycle.tsai@mediatek.com>
There are a lot of different structures that need to have a "frozen" abi
for the next 5+ years. Add padding to a lot of them in order to be able
to handle any future changes that might be needed due to LTS and
security fixes that might come up.
It's a best guess, based on what has happened in the past from the
5.4.0..5.4.129 release (1 1/2 years). Yes, past changes do not mean
that future changes will also be needed in the same area, but that is a
hint that those areas are both well maintained and looked after, and
there have been previous problems found in them.
Also the list of structures that are being required based on OEM usage
in the android/ symbol lists were consulted as that's a larger list than
what has been changed in the past.
Hopefully we caught everything we need to worry about, only time will
tell...
Bug: 151154716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I880bbcda0628a7459988eeb49d18655522697664
soc_pcm_open() does rollback when failed (A),
but, it is almost same as soc_pcm_close().
static int soc_pcm_open(xxx)
{
...
if (ret < 0)
goto xxx_err;
...
return 0;
^ config_err:
| ...
| rtd_startup_err:
(A) ...
| component_err:
| ...
v return ret;
}
The difference is
soc_pcm_close() is for all dai/component/substream,
rollback is for succeeded part only.
This kind of duplicated code can be a hotbed of bugs,
thus, we want to share soc_pcm_close() and rollback.
Now, soc_pcm_open/close() are handling
1) snd_soc_dai_startup/shutdown()
=> 2) snd_soc_link_startup/shutdown()
3) snd_soc_component_module_get/put()
4) snd_soc_component_open/close()
5) pm_runtime_put/get()
This patch is for 2) snd_soc_link_startup/shutdown().
The idea of having bit-flag or counter is not enough for this purpose.
For example if one DAI is used for 2xPlaybacks for some reasons,
and if 1st Playback was succeeded but 2nd Playback was failed,
2nd Playback rollback doesn't need to call shutdown.
But it has succeeded bit-flag or counter via 1st Playback,
thus, 2nd Playback rollback will call unneeded shutdown.
And 1st Playback's necessary shutdown will not be called,
because bit-flag or counter was cleared by wrong 2nd Playback rollback.
To avoid such case, this patch marks substream pointer when startup() was
succeeded. If rollback needed, it will check rollback flag and marked
substream pointer.
One note here is that it cares *current* startup() only now.
but we might want to check *whole* marked substream in the future.
This patch is using macro named "push/pop", so that it can be easily
update.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87k0webwnv.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 25612477d2 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
added snd_soc_dai_link_set_capabilities().
But it is using snd_soc_find_dai() (A) which is required client_mutex (B).
And client_mutex is soc-core.c local.
struct snd_soc_dai *snd_soc_find_dai(xxx)
{
...
(B) lockdep_assert_held(&client_mutex);
...
}
void snd_soc_dai_link_set_capabilities(xxx)
{
...
for_each_pcm_streams(direction) {
...
for_each_link_cpus(dai_link, i, cpu) {
(A) dai = snd_soc_find_dai(cpu);
...
}
...
for_each_link_codecs(dai_link, i, codec) {
(A) dai = snd_soc_find_dai(codec);
...
}
}
...
}
Because of these background, we will get WARNING if .config has CONFIG_LOCKDEP.
WARNING: CPU: 2 PID: 53 at sound/soc/soc-core.c:814 snd_soc_find_dai+0xf8/0x100
CPU: 2 PID: 53 Comm: kworker/2:1 Not tainted 5.7.0-rc1+ #328
Hardware name: Renesas H3ULCB Kingfisher board based on r8a77951 (DT)
Workqueue: events deferred_probe_work_func
pstate: 60000005 (nZCv daif -PAN -UAO)
pc : snd_soc_find_dai+0xf8/0x100
lr : snd_soc_find_dai+0xf4/0x100
...
Call trace:
snd_soc_find_dai+0xf8/0x100
snd_soc_dai_link_set_capabilities+0xa0/0x16c
graph_dai_link_of_dpcm+0x390/0x3c0
graph_for_each_link+0x134/0x200
graph_probe+0x144/0x230
platform_drv_probe+0x5c/0xb0
really_probe+0xe4/0x430
driver_probe_device+0x60/0xf4
snd_soc_find_dai() will be used from (X) CPU/Codec/Platform driver with
mutex lock, and (Y) Card driver without mutex lock.
This snd_soc_dai_link_set_capabilities() is for Card driver,
this means called without mutex.
This patch adds snd_soc_find_dai_with_mutex() to solve it.
Fixes: 25612477d2 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87blixvuab.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
commit 25612477d2 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
added snd_soc_dai_link_set_capabilities().
But it is using snd_soc_find_dai() (A) which is required client_mutex (B).
And client_mutex is soc-core.c local.
struct snd_soc_dai *snd_soc_find_dai(xxx)
{
...
(B) lockdep_assert_held(&client_mutex);
...
}
void snd_soc_dai_link_set_capabilities(xxx)
{
...
for_each_pcm_streams(direction) {
...
for_each_link_cpus(dai_link, i, cpu) {
(A) dai = snd_soc_find_dai(cpu);
...
}
...
for_each_link_codecs(dai_link, i, codec) {
(A) dai = snd_soc_find_dai(codec);
...
}
}
...
}
Because of these background, we will get WARNING if .config has CONFIG_LOCKDEP.
WARNING: CPU: 2 PID: 53 at sound/soc/soc-core.c:814 snd_soc_find_dai+0xf8/0x100
CPU: 2 PID: 53 Comm: kworker/2:1 Not tainted 5.7.0-rc1+ #328
Hardware name: Renesas H3ULCB Kingfisher board based on r8a77951 (DT)
Workqueue: events deferred_probe_work_func
pstate: 60000005 (nZCv daif -PAN -UAO)
pc : snd_soc_find_dai+0xf8/0x100
lr : snd_soc_find_dai+0xf4/0x100
...
Call trace:
snd_soc_find_dai+0xf8/0x100
snd_soc_dai_link_set_capabilities+0xa0/0x16c
graph_dai_link_of_dpcm+0x390/0x3c0
graph_for_each_link+0x134/0x200
graph_probe+0x144/0x230
platform_drv_probe+0x5c/0xb0
really_probe+0xe4/0x430
driver_probe_device+0x60/0xf4
snd_soc_find_dai() will be used from (X) CPU/Codec/Platform driver with
mutex lock, and (Y) Card driver without mutex lock.
This snd_soc_dai_link_set_capabilities() is for Card driver,
this means called without mutex.
This patch adds snd_soc_find_dai_with_mutex() to solve it.
Fixes: 25612477d2 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87blixvuab.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
simple-card.c and meson-card-utils.c use pretty much the same
helper function to parse auxiliary devices from the device tree.
Make it easier for other drivers to parse these from the device tree
as well by adding a shared helper function to soc-core.c.
snd_soc_of_parse_aux_devs() is pretty much a copy of
meson_card_add_aux_devices() from meson-card-utils.c
with two minor changes:
- Make property name configurable as parameter
- Change dev_err() message slightly for consistency with other
error messages in soc-core.c
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20200801100257.22658-1-stephan@gerhold.net
Signed-off-by: Mark Brown <broonie@kernel.org>
Partial 5.8-rc7 merge to make the final merge easier.
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I95f1b0a379e3810333300a70c5a93f449d945c54
ASoC: Fixes for v5.8
An awful lot of mostly small fixes here, mainly for x86 based platforms
and the CODEC drivers mainly used on them. For the most part this is
either minor device specific stuff which seems to come from detailed
testing or robustness against errors which comes from people having done
some fuzzing runs aginst the topology code.
While experimenting and introducing errors in Baytrail topology files
until I got them right, I encountered multiple kernel oopses and
memory leaks. This is a first batch to harden the code, but we should
probably think of a tool to fuzz the topology...
Pierre-Louis Bossart (5):
ASoC: topology: fix kernel oops on route addition error
ASoC: topology: fix tlvs in error handling for widget_dmixer
ASoC: topology: use break on errors, not continue
ASoC: topology: factor kfree(se) in error handling
ASoC: topology: add more logs when topology load fails.
sound/soc/soc-topology.c | 97 ++++++++++++++++++++++++----------------
1 file changed, 58 insertions(+), 39 deletions(-)
base-commit: a5911ac579
--
2.25.1
The ASoC devm_ functions that register a component
(devm_snd_soc_register_component and devm_snd_dmaengine_pcm_register) will
clean their component by running snd_soc_unregister_component.
snd_soc_unregister_component will then remove all the components for the
device that was used to register the component in the first place.
However, some drivers register several components (such as a DAI and a
dmaengine PCM) on the same device, and if the dmaengine PCM is registered
first, then the DAI will be cleaned up first and
snd_dmaengine_pcm_unregister will be called next.
snd_dmaengine_pcm_unregister will then lookup the dmaengine PCM component
on the device, and if there's one unregister that component and release its
dmaengine channels. That doesn't happen in practice though since the first
call to snd_soc_unregister_component removed all the components, so we
never get the chance to release the dmaengine channels.
In order to fix this, instead of removing all the components for a given
device, we can simply remove the component that was registered in the first
place. We should have the same number of component registration than we
have components, so it should work just fine.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20200707074237.287171-1-maxime@cerno.tech
Signed-off-by: Mark Brown <broonie@kernel.org>
Some machine drivers allocate or request resources with
snd_soc_link_init() phase of the card probe. These resources need to
be properly released when removing a card, and this patch suggests a
dual exit() callback.
The exit() is invoked in soc_remove_pcm_runtime(), which is not
completely symmetric with the init() invoked in soc_init_pcm_runtime().
Alternate solutions were considered, e.g. adding a .remove() callback
for the platform driver, but that's not symmetrical at all and would
be difficult to handle if there are more than one dailink implementing
an .init(). We looked also into using .remove_dai_link() callback, but
that would also be imbalanced.
Note that because of the error handling in snd_soc_bind_card(), which
jumps to probe_end, there is no way to guarantee the exit() is invoked
with resources allocated in the init(). Prior to releasing those
resources, implementations of the exit() callback shall check the
resources are valid.
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Curtis Malainey <curtis@malainey.com>
Link: https://lore.kernel.org/r/20200622154241.29053-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: Fixes for v5.8
This is a collection of mostly small fixes, mostly fixing fallout from
some of the DPCM changes that went in last time around which shook out
some issues on i.MX and Qualcomm platforms. The addition of a managed
version of snd_soc_register_dai() is to fix resource leaks.
There's also a few new device IDs for x86 systems.
We already have bit field to control snd_soc_card.
Let's add "probed" field on it instead of local variable.
One note here is that soc_cleanup_card_resources()
will be called as (A) formal cleanup or as (B) error handling,
thus, it needs to distinguish these.
In (A) case, card will have "instantiated" flag if all probe
callback functions were called without error.
Thus, snd_soc_unbind_card() is using it to judging card was probed.
But this this patch removes it, because it is no longer needed.
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/87r1v4zv36.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The newly added CODEC to CODEC DAI link widget pointers in
snd_soc_dai_link are better placed in snd_soc_pcm_runtime.
snd_soc_dai_link is really intended for static configuration of
the DAI, and the runtime for dynamic data. The snd_soc_dai_link
structures are not destroyed if the card is unbound. The widgets
are cleared up on unbind, however if the card is rebound as the
snd_soc_dai_link structures are reused these pointers will be left at
their old values, causing access to freed memory.
Fixes: 595571cca4 ("ASoC: dapm: Fix regression introducing multiple copies of DAI widgets")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200526161930.30759-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 7649773293 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20200507192228.GA16355@embeddedor
Signed-off-by: Mark Brown <broonie@kernel.org>
Old versions of gcc (tested on gcc-4.8) produce a warning for
correct code:
sound/soc/soc-compress.c: In function 'soc_compr_open':
sound/soc/soc-compress.c:75:28: error: 'component' is used uninitialized in this function [-Werror=uninitialized]
struct snd_soc_component *component, *save = NULL;
Change the for_each_rtd_components() macro to ensure 'component'
gets initialized to a value the compiler does not complain about.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20200428214754.3925368-1-arnd@arndb.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Refactoring was done to factor out the linking of DAI widgets into
a helper function, dapm_add_valid_dai_widget. However when this was
done, a regression was introduced for CODEC to CODEC links. It was
over looked that the playback and capture variables persisted across
all CODEC DAIs being processed, which ensured that the special DAI
widget that is added for CODEC to CODEC links was only created once.
This bug causes kernel panics during DAPM shutdown.
To stick with the spirit of the original refactoring whilst fixing the
issue, variables to hold the DAI widgets are added to snd_soc_dai_link.
Furthermore the dapm_add_valid_dai_widget function is renamed to
dapm_connect_dai_pair, the function only adds DAI widgets in the CODEC
to CODEC case and its primary job is to add routes connecting two DAI
widgets, making the original name quite misleading.
Fixes: 6c4b13b51a ("ASoC: Add dapm_add_valid_dai_widget helper")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200409181209.30130-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Now, snd_soc_pcm_runtime supports multi cpu_dai/codec_dai.
It still has cpu_dai/codec_dai for single DAI,
and has cpu_dais/codec_dais for multi DAIs.
dais = [][][][][][][][][][][][][][][][][][]
^cpu_dais ^codec_dais
|--- num_cpus ---|--- num_codecs --|
/* for multi DAIs */
rtd->cpu_dais = &rtd->dais[0];
rtd->codec_dais = &rtd->dais[dai_link->num_cpus];
/* for single DAI */
rtd->cpu_dai = rtd->cpu_dais[0];
rtd->codec_dai = rtd->codec_dais[0];
But, these can be replaced by dais.
This patch adds asoc_rtd_to_cpu() / asoc_rtd_to_codec() macro for it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/875zevk5va.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
