linux.git/include/sound/soc.h, branch v5.3.2

ASoC: soc-core: support dai_link with platforms_num != 1

2019-06-28T12:41:19+00:00

Add support platforms_num != 1 in dai_link. Initially, the main purpose of
this change was to make the platform optional in the dai_link, instead of
inserting the dummy platform driver.

This particular case had just been solved by Kuninori Morimoto with
commit 1d7689892878 ("ASoC: soc-core: allow no Platform on dai_link").

However, this change may still be useful for those who need multiple
platform components on a single dai_link (it solves one of the FIXME
note in soc-core)

Acked-by: Kuninori Morimoto 
Signed-off-by: Jerome Brunet 
Signed-off-by: Mark Brown

ASoC: soc-core: allow no Platform on dai_link

2019-06-19T11:47:03+00:00

dai_link is used to selecting Component (= CPU/Codec/Platform) and
DAI (= CPU/Codec). And selected CPU/Codec/Platform components are
*listed* on Card.

Many drivers don't need special Platform component, but was
mandatory at legacy style ALSA SoC.
Thus, there is this kind of settings on many drivers.

	dai_link->platform_of_node = dai_link->cpu_of_node;

In this case, soc_bind_dai_link() will pick-up "CPU component" as
"Platform component", and try to add it to snd_soc_pcm_runtime.
But it will be ignored, because it is already added when CPU bindings.

Historically, this kind of "CPU component" is used/selected as
"Platform" on many ALSA SoC drivers.
OTOH, Dummy Platform will be selected automatically by ALSA SoC if
driver doesn't have Platform settings.

These indicates that there are 2 type of Platforms exist at current
ALSA SoC if driver doesn't need special Platform.

	1) use Dummy Platform as Platform component
	2) use CPU component  as Platform component

ALSA SoC will call Dummy Platform callback function if it is using
Dummy Platform, but it is completely pointless. Because it is the
sound card which doesn't need special Platform.

Thus, the behavior we request to ALSA SoC is selecting 2) automatically
instead of 1) if sound card doesn't need special Platform.
And, 2) means "do nothing" as above explain.

These were needed at legacy style dai_link, but is no longer needed
at modern style dai_link anymore.

This patch allows "no Platform" settings on dai_link, and will do
nothing for it if there was no platform settings. This is same as 2).

By this patch, all drivers which is selecting "CPU component" as
"Platform" can remove such settings.

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Mark Brown

ASoC: soc.h: fixup for_each_card_links() macro

2019-06-19T10:51:52+00:00

Macro is using "link", not "dai_link"

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Mark Brown

ASoC: soc-core: remove legacy style dai_link

2019-06-06T21:20:29+00:00

All drivers switched to modern style dai_link
(= struct snd_soc_dai_link_component).
Let's remove legacy style dai_link.

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Mark Brown

ASoC: soc.h: add sound dai_link connection macro

2019-06-06T20:22:42+00:00

Modern style dai_link requests CPU/Codec/Platform component
pointer array and its size, but it will be very verbose code.
To avoid such scene, this patch adds dai_link connection macro.

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Mark Brown

ASoC: soc-core: use snd_soc_dai_link_component for CPU

2019-06-06T20:19:57+00:00

current ALSA SoC is starting to support modern style dai_linke
(= struct snd_soc_dai_link_component) which is mainly used for
multipul DAI/component connection.
Now Codec has full multi-codec support, Platform is using modern
style but still for single Platform.
Only CPU is not yet supporting modern style yet.
If we could support it for CPU, we can switch to modern style
dai_link on all CPU/Codec/Platform, and remove legacy style
from ALSA SoC.

Multi-CPU will be supported in the future.
This patch is initial support for modern style for CPU

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Mark Brown

ASoC: soc.h: fe_compr can be bit field

2019-05-13T11:45:07+00:00

fe_compr is used at soc-compress, it can be bit field.
This patch move it from int to bit field.

> grep fe_compr -r sound/soc/*
sound/soc/soc-compress.c:               rtd->fe_compr = 1;
sound/soc/soc-pcm.c:            if (!fe->dpcm[stream].runtime && !fe->fe_compr)

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Mark Brown

ASoC: core: conditionally increase module refcount on component open

2019-04-08T07:15:44+00:00

Recently, for Intel platforms the "ignore_module_refcount" field
was introduced for the component driver. In order to avoid a
deadlock preventing the PCI modules from being removed
even when the card was idle, the refcounts were not incremented
for the device driver module during component probe.

However, this change introduced a nasty side effect:
the device driver module can be unloaded while a pcm stream is open.

This patch proposes to change the field to be renamed as
"module_get_upon_open". When this field is set, the module
refcount should be incremented on pcm open amd decremented
upon pcm close. This will enable modules to be removed
when no PCM playback/capture happens and prevent removal
when the component is actually in use.

Also, align with the skylake component driver with the new name.

Fixes: b450b878('ASoC: core: don't increase component module refcount
                 unconditionally'
Signed-off-by: Ranjani Sridharan 
Acked-by: Pierre-Louis Bossart 
Signed-off-by: Mark Brown

ASoC: dpcm: prevent snd_soc_dpcm use after free

2019-03-11T16:58:49+00:00

The dpcm get from fe_clients/be_clients
may be free before use

Add a spin lock at snd_soc_card level,
to protect the dpcm instance.
The lock may be used in atomic context, so use spin lock.

Use irq spin lock version,
since the lock may be used in interrupts.

possible race condition between
void dpcm_be_disconnect(
	...
	list_del(&dpcm->list_be);
	list_del(&dpcm->list_fe);
	kfree(dpcm);
	...

and
	for_each_dpcm_fe()
	for_each_dpcm_be*()

race condition example
Thread 1:
    snd_soc_dapm_mixer_update_power()
        -> soc_dpcm_runtime_update()
            -> dpcm_be_disconnect()
                -> kfree(dpcm);
Thread 2:
    dpcm_fe_dai_trigger()
        -> dpcm_be_dai_trigger()
            -> snd_soc_dpcm_can_be_free_stop()
                -> if (dpcm->fe == fe)

Excpetion Scenario:
	two FE link to same BE
	FE1 -> BE
	FE2 ->

	Thread 1: switch of mixer between FE2 -> BE
	Thread 2: pcm_stop FE1

Exception:

Unable to handle kernel paging request at virtual address dead0000000000e0

pc=<> [] dpcm_be_dai_trigger+0x29c/0x47c
	sound/soc/soc-pcm.c:3226
		if (dpcm->fe == fe)
lr=<> [] dpcm_fe_dai_do_trigger+0x94/0x26c

Backtrace:
[] notify_die+0x68/0xb8
[] die+0x118/0x2a8
[] __do_kernel_fault+0x13c/0x14c
[] do_translation_fault+0x64/0xa0
[] do_mem_abort+0x4c/0xd0
[] el1_da+0x24/0x40
[] dpcm_be_dai_trigger+0x29c/0x47c
[] dpcm_fe_dai_do_trigger+0x94/0x26c
[] dpcm_fe_dai_trigger+0x3c/0x44
[] snd_pcm_do_stop+0x50/0x5c
[] snd_pcm_action+0xb4/0x13c
[] snd_pcm_drop+0xa0/0x128
[] snd_pcm_common_ioctl+0x9d8/0x30f0
[] snd_pcm_ioctl_compat+0x29c/0x2f14
[] compat_SyS_ioctl+0x128/0x244
[] el0_svc_naked+0x34/0x38
[] 0xffffffffffffffff

Signed-off-by: KaiChieh Chuang 
Signed-off-by: Mark Brown

ASoC: core: don't increase component module refcount unconditionally

2019-02-08T18:00:20+00:00

The ASoC core has for the longest time increased the module reference
counts, even before the transition to the component model. This is
probably fine on most platforms, but it introduces a deadlock case on
Intel devices with the Skylake and SOF drivers which cannot be removed
due to their reference counts being modified by the core.

In these 2 cases, the PCI or ACPI driver .probe creates a platform
device to let the machine driver .probe register the audio
card. Conversely the PCI or ACPI driver .remove will unregister the
platform device which results in the card being removed by the machine
driver .remove.

With ascii art, this can be represented as

modprobe
snd_soc_skl/
soc-pci-dev/sof-acpci-dev  ----------> pci/acpi probe
       ^                                    |
       |                     ---------------|
       |                    |               |
       |                    V               V
    increase            register        register machine
    refcount            component       platform_device
       ^                                    |
       |                                    |
       |                                    V
    component <----   register card  <---- probe
    probe

The issue is that by playing with the component's module reference
counts during the card registration, it's no longer possible to remove
the module which controls the component. This can be shown, e.g. with
the following error:

root@plb-XPS-13-9350:~# lsmod | grep snd_soc_skl
snd_soc_skl           110592  1

root@plb-XPS-13-9350:~# rmmod snd_soc_skl
rmmod: ERROR: Module snd_soc_skl is in use

Increasing the reference count during the component probe is not
useful. If the PCI/ACPI module is removed, the card will be removed
anyway.

To avoid breaking existing platforms and allowing Intel platforms to
safely deal with module load/unload cases, this patch introduces a
flag which needs to be set during the component initialization. This
is a strictly opt-in capability that should only be used when the
handling of the component module does not require a reference count
increase to prevent removal during use.

Note that this solution is not directly applicable to the legacy
Atom/SST driver, which uses a different device hierarchy. There are
however additional refcount issues which prevent the ACPI driver from
being removed. This is a different issue which would need a different
patch.

Signed-off-by: Pierre-Louis Bossart 
Signed-off-by: Mark Brown