2019-05-27 08:55:05 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-15 09:50:19 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-01-29 11:46:11 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-01-16 16:29:08 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-08-08 17:06:01 +02:00
|
|
|
|
2013-08-16 11:18:59 -06:00
|
|
|
|
ALSA: control: Use xarray for faster lookups
The control elements are managed in a single linked list and we
traverse the whole list for matching each numid or ctl id per every
inquiry of a control element. This is OK-ish for a small number of
elements but obviously it doesn't scale. Especially the matching with
the ctl id takes time because it checks each field of the snd_ctl_id
element, e.g. the name string is matched with strcmp().
This patch adds the hash tables with Xarray for improving the lookup
speed of a control element. There are two xarray tables added to the
card; one for numid and another for ctl id. For the numid, we use the
numid as the index, while for the ctl id, we calculate a hash key.
The lookup is done via a single xa_load() execution. As long as the
given control element is found on the Xarray table, that's fine, we
can give back a quick lookup result. The problem is when no entry
hits on the table, and for this case, we have a slight optimization.
Namely, the driver checks whether we had a collision on Xarray table,
and do a fallback search (linear lookup of the full entries) only if a
hash key collision happened beforehand.
So, in theory, the inquiry for a non-existing element might take still
time even with this patch in a worst case, but this must be pretty
rare.
The feature is enabled via CONFIG_SND_CTL_FAST_LOOKUP, which is turned
on as default. For simplicity, the option can be turned off only when
CONFIG_EXPERT is set ("You are expert? Then you manage 1000 knobs").
Link: https://lore.kernel.org/r/20211028130027.18764-1-tiwai@suse.de
Link: https://lore.kernel.org/r/20220609180504.775-1-tiwai@suse.de
Link: https://lore.kernel.org/all/cover.1653813866.git.quic_rbankapu@quicinc.com/
Link: https://lore.kernel.org/r/20220610064537.18660-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-06-10 08:45:37 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-01-08 18:13:27 +01:00
|
|
|
|
|
|
|
|
|
ALSA: Add kconfig to specify the max card numbers
Currently ALSA supports up to 32 card instances when the dynamic minor
is used. While 32 cards are usually big enough for normal use cases,
there are sometimes weird requirements with more card support.
Actually, this limitation, 32, comes from the index option, where you
can pass the bit mask to assign the card. Other than that, we can
actually give more cards up to the minor number limits (currently 256,
which can be extended more, too).
This patch adds a new Kconfig to specify the max card numbers, and
changes a few places to accept more than 32 cards.
The only incompatibility with high card numbers would be the handling
of index option. The index option can be still used to pass the
bitmask for card assignments, but this works only up to 32 slots.
More than 32, no bitmask style option is available but only a single
slot can be specified via index option.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-05-15 08:46:39 +02:00
|
|
|
|
2008-01-08 18:13:27 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-05-26 13:46:22 -04:00
|
|
|
|
2014-01-29 12:13:43 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ALSA: Use priority list for managing device list
Basically, the device type specifies the priority of the device to be
registered / freed, too. However, the priority value isn't well
utilized but only it's checked as a group. This results in
inconsistent register and free order (where each of them should be in
reversed direction).
This patch simplifies the device list management code by simply
inserting a list entry at creation time in an incremental order for
the priority value. Since we can just follow the link for register,
disconnect and free calls, we don't have to specify the group; so the
whole enum definitions are also simplified as well.
The visible change to outside is that the priorities of some object
types are revisited. For example, now the SNDRV_DEV_LOWLEVEL object
is registered before others (control, PCM, etc) and, in return,
released after others. Similarly, SNDRV_DEV_CODEC is in a lower
priority than SNDRV_DEV_BUS for ensuring the dependency.
Also, the unused SNDRV_DEV_TOPLEVEL, SNDRV_DEV_LOWLEVEL_PRE and
SNDRV_DEV_LOWLEVEL_NORMAL are removed as a cleanup.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-01-29 15:53:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-29 15:13:33 +01:00
|
|
|
|
ALSA: Use priority list for managing device list
Basically, the device type specifies the priority of the device to be
registered / freed, too. However, the priority value isn't well
utilized but only it's checked as a group. This results in
inconsistent register and free order (where each of them should be in
reversed direction).
This patch simplifies the device list management code by simply
inserting a list entry at creation time in an incremental order for
the priority value. Since we can just follow the link for register,
disconnect and free calls, we don't have to specify the group; so the
whole enum definitions are also simplified as well.
The visible change to outside is that the priorities of some object
types are revisited. For example, now the SNDRV_DEV_LOWLEVEL object
is registered before others (control, PCM, etc) and, in return,
released after others. Similarly, SNDRV_DEV_CODEC is in a lower
priority than SNDRV_DEV_BUS for ensuring the dependency.
Also, the unused SNDRV_DEV_TOPLEVEL, SNDRV_DEV_LOWLEVEL_PRE and
SNDRV_DEV_LOWLEVEL_NORMAL are removed as a cleanup.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-01-29 15:53:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-29 15:13:33 +01:00
|
|
|
|
ALSA: Use priority list for managing device list
Basically, the device type specifies the priority of the device to be
registered / freed, too. However, the priority value isn't well
utilized but only it's checked as a group. This results in
inconsistent register and free order (where each of them should be in
reversed direction).
This patch simplifies the device list management code by simply
inserting a list entry at creation time in an incremental order for
the priority value. Since we can just follow the link for register,
disconnect and free calls, we don't have to specify the group; so the
whole enum definitions are also simplified as well.
The visible change to outside is that the priorities of some object
types are revisited. For example, now the SNDRV_DEV_LOWLEVEL object
is registered before others (control, PCM, etc) and, in return,
released after others. Similarly, SNDRV_DEV_CODEC is in a lower
priority than SNDRV_DEV_BUS for ensuring the dependency.
Also, the unused SNDRV_DEV_TOPLEVEL, SNDRV_DEV_LOWLEVEL_PRE and
SNDRV_DEV_LOWLEVEL_NORMAL are removed as a cleanup.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2014-01-29 15:53:35 +01:00
|
|
|
|
2014-01-29 15:13:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ALSA: core: Assure control device to be registered at last
The commit 289ca025ee1d ("ALSA: Use priority list for managing device
list") changed the way to register/disconnect/free devices via a
single priority list. This helped to make behavior consistent, but it
also changed a slight behavior change: namely, the control device is
registered earlier than others, while it was supposed to be the very
last one.
I've put SNDRV_DEV_CONTROL in the current position as the release of
ctl elements often conflict with the private ctl elements some PCM or
other components may create, which often leads to a double-free.
But, the order of register and disconnect should be indeed fixed as
expected in the early days: the control device gets registered at
last, and disconnected at first.
This patch changes the priority list order to move SNDRV_DEV_CONTROL
as the last guy to assure the register / disconnect order. Meanwhile,
for keeping the messy resource release order, manually treat the
control and lowlevel devices as last freed one.
Additional note:
The lowlevel device is the device where a card driver creates at
probe. And, we still keep the release order control -> lowlevel, as
there might be link from a control element back to a lowlevel object.
Fixes: 289ca025ee1d ("ALSA: Use priority list for managing device list")
Reported-by: Tzung-Bi Shih <tzungbi@google.com>
Tested-by: Tzung-Bi Shih <tzungbi@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-05-15 20:25:29 +02:00
|
|
|
|
2014-01-29 15:13:33 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-01-29 15:13:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-11-17 13:51:18 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-11-17 13:51:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-11-17 13:51:18 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-11-17 13:51:18 +01:00
|
|
|
|
2014-01-29 15:13:33 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2020-01-03 09:16:19 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-11-17 13:51:18 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2026-06-10 17:45:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-11-17 13:51:18 +01:00
|
|
|
|
2005-06-29 19:31:06 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-22 19:09:05 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-10-07 11:38:09 +02:00
|
|
|
|
2005-06-29 19:31:06 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-17 13:51:18 +01:00
|
|
|
|
2005-06-29 19:31:06 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2023-08-16 18:02:45 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-04-28 11:59:40 +02:00
|
|
|
|
2024-08-09 12:42:30 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
ALSA: control: Add memory consumption limit to user controls
ALSA control interface allows users to add arbitrary control elements
(called "user controls" or "user elements"), and its resource usage is
limited just by the max number of control sets (currently 32). This
limit, however, is quite loose: each allocation of control set may
have 1028 elements, and each element may have up to 512 bytes (ILP32) or
1024 bytes (LP64) of value data. Moreover, each control set may contain
the enum strings and TLV data, which can be up to 64kB and 128kB,
respectively. Totally, the whole memory consumption may go over 38MB --
it's quite large, and we'd rather like to reduce the size.
OTOH, there have been other requests even to increase the max number
of user elements; e.g. ALSA firewire stack require the more user
controls, hence we want to raise the bar, too.
For satisfying both requirements, this patch changes the management of
user controls: instead of setting the upper limit of the number of
user controls, we check the actual memory allocation size and set the
upper limit of the total allocation in bytes. As long as the memory
consumption stays below the limit, more user controls are allowed than
the current limit 32. At the same time, we set the lower limit (8MB)
as default than the current theoretical limit, in order to lower the
risk of DoS.
As a compromise for lowering the default limit, now the actual memory
limit is defined as a module option, 'max_user_ctl_alloc_size', so that
user can increase/decrease the limit if really needed, too.
Link: https://lore.kernel.org/r/s5htur3zl5e.wl-tiwai@suse.de
Co-developed-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Tested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210408103149.40357-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-04-08 19:31:49 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
ALSA: control: Use xarray for faster lookups
The control elements are managed in a single linked list and we
traverse the whole list for matching each numid or ctl id per every
inquiry of a control element. This is OK-ish for a small number of
elements but obviously it doesn't scale. Especially the matching with
the ctl id takes time because it checks each field of the snd_ctl_id
element, e.g. the name string is matched with strcmp().
This patch adds the hash tables with Xarray for improving the lookup
speed of a control element. There are two xarray tables added to the
card; one for numid and another for ctl id. For the numid, we use the
numid as the index, while for the ctl id, we calculate a hash key.
The lookup is done via a single xa_load() execution. As long as the
given control element is found on the Xarray table, that's fine, we
can give back a quick lookup result. The problem is when no entry
hits on the table, and for this case, we have a slight optimization.
Namely, the driver checks whether we had a collision on Xarray table,
and do a fallback search (linear lookup of the full entries) only if a
hash key collision happened beforehand.
So, in theory, the inquiry for a non-existing element might take still
time even with this patch in a worst case, but this must be pretty
rare.
The feature is enabled via CONFIG_SND_CTL_FAST_LOOKUP, which is turned
on as default. For simplicity, the option can be turned off only when
CONFIG_EXPERT is set ("You are expert? Then you manage 1000 knobs").
Link: https://lore.kernel.org/r/20211028130027.18764-1-tiwai@suse.de
Link: https://lore.kernel.org/r/20220609180504.775-1-tiwai@suse.de
Link: https://lore.kernel.org/all/cover.1653813866.git.quic_rbankapu@quicinc.com/
Link: https://lore.kernel.org/r/20220610064537.18660-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-06-10 08:45:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-11-17 13:51:18 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-02-23 16:35:21 +01:00
|
|
|
|
2005-06-29 19:31:06 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-01-29 12:13:43 +01:00
|
|
|
|
2007-01-26 12:40:31 +01:00
|
|
|
|
2014-01-29 11:46:11 +01:00
|
|
|
|
2015-01-30 12:27:43 +01:00
|
|
|
|
2014-01-29 11:46:11 +01:00
|
|
|
|
ALSA: core: Add managed card creation
As a second step for preliminary to widen the devres usages among
sound drivers, this patch adds a new ALSA core API function,
snd_devm_card_new(), to create a snd_card object via devres.
When a card object is created by this new function, snd_card_free() is
called automatically and the card object resource gets released at the
device unbinding time.
However, the story isn't that simple. A caveat is that we have to
call snd_card_free() at the very first of the whole resource release
procedure, in order to assure that the all exposed devices on
user-space are deleted and sync with processes accessing those devices
before releasing resources.
For achieving it, snd_card_register() adds a new devres action to
trigger snd_card_free() automatically when the given card object is a
"managed" one. Since usually snd_card_register() is the last step of
the initialization, this should work in most cases.
With all these tricks, some drivers can get rid of the whole driver
remove callback code.
About a bit of implementation details: the patch adds two new flags to
snd_card object: managed and releasing. The former indicates that the
object was created via snd_devm_card_new(), and the latter is used for
avoiding the double-free of snd_card_free() calls. Both flags are
fairly internal and likely uninteresting to normal users.
Link: https://lore.kernel.org/r/20210715075941.23332-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-07-15 09:58:24 +02:00
|
|
|
|
|
|
|
|
|
2019-11-17 09:53:07 +01:00
|
|
|
|
ALSA: add snd_card_disconnect_sync()
In case of user unbind ALSA driver during playing back / capturing,
each driver needs to stop and remove it correctly. One note here is
that we can't cancel from remove function in such case, because
unbind operation doesn't check return value from remove function.
So, we *must* stop and remove in this case.
For this purpose, we need to sync (= wait) until the all top-level
operations are canceled at remove function.
For example, snd_card_free() processes the disconnection procedure at
first, then waits for the completion. That's how the hot-unplug works
safely. It's implemented, at least, in the top-level driver removal.
Now for the lower level driver, we need a similar strategy. Notify to
the toplevel for hot-unplug (disconnect in ALSA), and sync with the
stop operation, then continue the rest of its own remove procedure.
This patch adds snd_card_disconnect_sync(), and driver can use it from
remove function.
Note: the "lower level" driver here refers to a middle layer driver
(e.g. ASoC components) that can be unbound freely during operation.
Most of legacy ALSA helper drivers don't have such a problem because
they can't be unbound.
Note#2: snd_card_disconnect_sync() merely calls snd_card_disconnect()
and syncs with closing all pending files. It takes only the files
opened by user-space into account, and doesn't care about object
refcounts. (The latter is handled by snd_card_free() completion call,
BTW.) Also, the function doesn't free resources by itself.
Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-10-11 06:36:13 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
ALSA: pcm: Set per-card upper limit of PCM buffer allocations
Currently, the available buffer allocation size for a PCM stream
depends on the preallocated size; when a buffer has been preallocated,
the max buffer size is set to that size, so that application won't
re-allocate too much memory. OTOH, when no preallocation is done,
each substream may allocate arbitrary size of buffers as long as
snd_pcm_hardware.buffer_bytes_max allows -- which can be quite high,
HD-audio sets 1GB there.
It means that the system may consume a high amount of pages for PCM
buffers, and they are pinned and never swapped out. This can lead to
OOM easily.
For avoiding such a situation, this patch adds the upper limit per
card. Each snd_pcm_lib_malloc_pages() and _free_pages() calls are
tracked and it will return an error if the total amount of buffers
goes over the defined upper limit. The default value is set to 32MB,
which should be really large enough for usual operations.
If larger buffers are needed for any specific usage, it can be
adjusted (also dynamically) via snd_pcm.max_alloc_per_card option.
Setting zero there means no chceck is performed, and again, unlimited
amount of buffers are allowed.
Link: https://lore.kernel.org/r/20200120124423.11862-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-20 13:44:22 +01:00
|
|
|
|
|
|
|
|
|
ALSA: jack: implement software jack injection via debugfs
This change adds audio jack injection feature through debugfs, with
this feature, we could validate alsa userspace changes by injecting
plugin or plugout events to the non-phantom audio jacks.
With this change, the sound core will build the folders
$debugfs_mount_dir/sound/cardN if SND_DEBUG and DEBUG_FS are enabled.
And if users also enable the SND_JACK_INJECTION_DEBUG, the jack
injection nodes will be built in the folder cardN like below:
$tree $debugfs_mount_dir/sound
$debugfs_mount_dir/sound
├── card0
│ ├── HDMI_DP_pcm_10_Jack
│ │ ├── jackin_inject
│ │ ├── kctl_id
│ │ ├── mask_bits
│ │ ├── status
│ │ ├── sw_inject_enable
│ │ └── type
...
│ └── HDMI_DP_pcm_9_Jack
│ ├── jackin_inject
│ ├── kctl_id
│ ├── mask_bits
│ ├── status
│ ├── sw_inject_enable
│ └── type
└── card1
├── HDMI_DP_pcm_5_Jack
│ ├── jackin_inject
│ ├── kctl_id
│ ├── mask_bits
│ ├── status
│ ├── sw_inject_enable
│ └── type
...
├── Headphone_Jack
│ ├── jackin_inject
│ ├── kctl_id
│ ├── mask_bits
│ ├── status
│ ├── sw_inject_enable
│ └── type
└── Headset_Mic_Jack
├── jackin_inject
├── kctl_id
├── mask_bits
├── status
├── sw_inject_enable
└── type
The nodes kctl_id, mask_bits, status and type are read-only, users
could check jack or jack_kctl's information through them.
The nodes sw_inject_enable and jackin_inject are directly used for
injection. The sw_inject_enable is read-write, users could check if
software injection is enabled or not on this jack, and users could
echo 1 or 0 to enable or disable software injection on this jack. Once
the injection is enabled, the jack will not change by hardware events
anymore, once the injection is disabled, the jack will restore the
last reported hardware events to the jack. The jackin_inject is
write-only, if the injection is enabled, users could echo 1 or 0 to
this node to inject plugin or plugout events to this jack.
For the detailed usage information on these nodes, please refer to
Documentation/sound/designs/jack-injection.rst.
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20210127085639.74954-2-hui.wang@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-01-27 16:56:39 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ALSA: control: Verify put() result when in debug mode
The put() operation is expected to return:
1) 0 on success if no changes were made
2) 1 on success if changes were made
3) error code otherwise
Currently 2) is usually ignored when writing control-operations. While
forcing compliance is not an option right now, make it easier for
developers to adhere to the expectations and notice problems by logging
them when CONFIG_SND_CTL_DEBUG is enabled.
Due to large size of struct snd_ctl_elem_value, 'value_buf' is provided
as a reusable buffer for kctl->put() verification. This prevents
exhausting the stack when verifying the operation.
>From user perspective, patch introduces a new trace/events category
'snd_ctl' containing a single 'snd_ctl_put' event type. Log sample:
amixer-1086 [003] ..... 8.035939: snd_ctl_put: success: expected=0, actual=0 for ctl numid=1, iface=MIXER, name='Master Playback Volume', index=0, device=0, subdevice=0, card=0
amixer-1087 [003] ..... 8.938721: snd_ctl_put: success: expected=1, actual=1 for ctl numid=1, iface=MIXER, name='Master Playback Volume', index=0, device=0, subdevice=0, card=0
amixer-1088 [003] ..... 9.631470: snd_ctl_put: success: expected=1, actual=1 for ctl numid=1, iface=MIXER, name='Master Playback Volume', index=0, device=0, subdevice=0, card=0
amixer-1089 [000] ..... 9.636786: snd_ctl_put: fail: expected=1, actual=0 for ctl numid=5, iface=MIXER, name='Loopback Mute', index=0, device=0, subdevice=0, card=0
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260224205619.584795-1-cezary.rojewski@intel.com
2026-02-24 21:56:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ALSA: pcm: Set per-card upper limit of PCM buffer allocations
Currently, the available buffer allocation size for a PCM stream
depends on the preallocated size; when a buffer has been preallocated,
the max buffer size is set to that size, so that application won't
re-allocate too much memory. OTOH, when no preallocation is done,
each substream may allocate arbitrary size of buffers as long as
snd_pcm_hardware.buffer_bytes_max allows -- which can be quite high,
HD-audio sets 1GB there.
It means that the system may consume a high amount of pages for PCM
buffers, and they are pinned and never swapped out. This can lead to
OOM easily.
For avoiding such a situation, this patch adds the upper limit per
card. Each snd_pcm_lib_malloc_pages() and _free_pages() calls are
tracked and it will return an error if the total amount of buffers
goes over the defined upper limit. The default value is set to 32MB,
which should be really large enough for usual operations.
If larger buffers are needed for any specific usage, it can be
adjusted (also dynamically) via snd_pcm.max_alloc_per_card option.
Setting zero there means no chceck is performed, and again, unlimited
amount of buffers are allowed.
Link: https://lore.kernel.org/r/20200120124423.11862-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-20 13:44:22 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-06-10 17:45:32 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2017-05-12 11:44:03 +02:00
|
|
|
|
2005-11-17 13:51:18 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2026-05-31 22:23:35 -03:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-01-29 11:46:11 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-11-17 13:51:18 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-05-23 11:09:15 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-11-17 13:51:18 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-05-23 11:09:15 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-06-29 19:31:06 +02:00
|
|
|
|
ALSA: control: Track in-flight control read/write/tlv accesses
Although the power state check is performed in various places (e.g. at
the entrance of quite a few ioctls), there can be still some pending
tasks that already went into the ioctl handler or other ops, and those
may access the hardware even after the power state check. For
example, kcontrol access ioctl paths that call info/get/put callbacks
may update the hardware registers. If a system wants to assure the
free from such hw access (like the case of PCI rescan feature we're
going to implement in future), this situation must be avoided, and we
have to sync such in-flight tasks finishing beforehand.
For that purpose, this patch introduces a few new things in core code:
- A refcount, power_ref, and a wait queue, power_ref_sleep, to the
card object
- A few new helpers, snd_power_ref(), snd_power_unref(),
snd_power_ref_and_wait(), and snd_power_sync_ref()
In the code paths that call kctl info/read/write/tlv ops, we check the
power state with the newly introduced snd_power_ref_and_wait(). This
function also takes the card.power_ref refcount for tracking this
in-flight task. Once after the access finishes, snd_power_unref() is
called to released the refcount in return. So the driver can sync via
snd_power_sync_ref() assuring that all in-flight tasks have been
finished.
As of this patch, snd_power_sync_ref() is called only at
snd_card_disconnect(), but it'll be used in other places in future.
Note that atomic_t is used for power_ref intentionally instead of
refcount_t. It's because of the design of refcount_t type; refcount_t
cannot be zero-based, and it cannot do dec_and_test() call for
multiple times, hence it's not suitable for our purpose.
Also, this patch changes snd_power_wait() to accept only
SNDRV_CTL_POWER_D0, which is the only value that makes sense.
In later patch, the snd_power_wait() calls will be cleaned up.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20210523090920.15345-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-05-23 11:09:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-06-10 17:45:32 +02:00
|
|
|
|
ALSA: control: Track in-flight control read/write/tlv accesses
Although the power state check is performed in various places (e.g. at
the entrance of quite a few ioctls), there can be still some pending
tasks that already went into the ioctl handler or other ops, and those
may access the hardware even after the power state check. For
example, kcontrol access ioctl paths that call info/get/put callbacks
may update the hardware registers. If a system wants to assure the
free from such hw access (like the case of PCI rescan feature we're
going to implement in future), this situation must be avoided, and we
have to sync such in-flight tasks finishing beforehand.
For that purpose, this patch introduces a few new things in core code:
- A refcount, power_ref, and a wait queue, power_ref_sleep, to the
card object
- A few new helpers, snd_power_ref(), snd_power_unref(),
snd_power_ref_and_wait(), and snd_power_sync_ref()
In the code paths that call kctl info/read/write/tlv ops, we check the
power state with the newly introduced snd_power_ref_and_wait(). This
function also takes the card.power_ref refcount for tracking this
in-flight task. Once after the access finishes, snd_power_unref() is
called to released the refcount in return. So the driver can sync via
snd_power_sync_ref() assuring that all in-flight tasks have been
finished.
As of this patch, snd_power_sync_ref() is called only at
snd_card_disconnect(), but it'll be used in other places in future.
Note that atomic_t is used for power_ref intentionally instead of
refcount_t. It's because of the design of refcount_t type; refcount_t
cannot be zero-based, and it cannot do dec_and_test() call for
multiple times, hence it's not suitable for our purpose.
Also, this patch changes snd_power_wait() to accept only
SNDRV_CTL_POWER_D0, which is the only value that makes sense.
In later patch, the snd_power_wait() calls will be cleaned up.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20210523090920.15345-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-05-23 11:09:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-06-10 17:45:32 +02:00
|
|
|
|
ALSA: control: Track in-flight control read/write/tlv accesses
Although the power state check is performed in various places (e.g. at
the entrance of quite a few ioctls), there can be still some pending
tasks that already went into the ioctl handler or other ops, and those
may access the hardware even after the power state check. For
example, kcontrol access ioctl paths that call info/get/put callbacks
may update the hardware registers. If a system wants to assure the
free from such hw access (like the case of PCI rescan feature we're
going to implement in future), this situation must be avoided, and we
have to sync such in-flight tasks finishing beforehand.
For that purpose, this patch introduces a few new things in core code:
- A refcount, power_ref, and a wait queue, power_ref_sleep, to the
card object
- A few new helpers, snd_power_ref(), snd_power_unref(),
snd_power_ref_and_wait(), and snd_power_sync_ref()
In the code paths that call kctl info/read/write/tlv ops, we check the
power state with the newly introduced snd_power_ref_and_wait(). This
function also takes the card.power_ref refcount for tracking this
in-flight task. Once after the access finishes, snd_power_unref() is
called to released the refcount in return. So the driver can sync via
snd_power_sync_ref() assuring that all in-flight tasks have been
finished.
As of this patch, snd_power_sync_ref() is called only at
snd_card_disconnect(), but it'll be used in other places in future.
Note that atomic_t is used for power_ref intentionally instead of
refcount_t. It's because of the design of refcount_t type; refcount_t
cannot be zero-based, and it cannot do dec_and_test() call for
multiple times, hence it's not suitable for our purpose.
Also, this patch changes snd_power_wait() to accept only
SNDRV_CTL_POWER_D0, which is the only value that makes sense.
In later patch, the snd_power_wait() calls will be cleaned up.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20210523090920.15345-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-05-23 11:09:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-06-10 17:45:32 +02:00
|
|
|
|
ALSA: control: Track in-flight control read/write/tlv accesses
Although the power state check is performed in various places (e.g. at
the entrance of quite a few ioctls), there can be still some pending
tasks that already went into the ioctl handler or other ops, and those
may access the hardware even after the power state check. For
example, kcontrol access ioctl paths that call info/get/put callbacks
may update the hardware registers. If a system wants to assure the
free from such hw access (like the case of PCI rescan feature we're
going to implement in future), this situation must be avoided, and we
have to sync such in-flight tasks finishing beforehand.
For that purpose, this patch introduces a few new things in core code:
- A refcount, power_ref, and a wait queue, power_ref_sleep, to the
card object
- A few new helpers, snd_power_ref(), snd_power_unref(),
snd_power_ref_and_wait(), and snd_power_sync_ref()
In the code paths that call kctl info/read/write/tlv ops, we check the
power state with the newly introduced snd_power_ref_and_wait(). This
function also takes the card.power_ref refcount for tracking this
in-flight task. Once after the access finishes, snd_power_unref() is
called to released the refcount in return. So the driver can sync via
snd_power_sync_ref() assuring that all in-flight tasks have been
finished.
As of this patch, snd_power_sync_ref() is called only at
snd_card_disconnect(), but it'll be used in other places in future.
Note that atomic_t is used for power_ref intentionally instead of
refcount_t. It's because of the design of refcount_t type; refcount_t
cannot be zero-based, and it cannot do dec_and_test() call for
multiple times, hence it's not suitable for our purpose.
Also, this patch changes snd_power_wait() to accept only
SNDRV_CTL_POWER_D0, which is the only value that makes sense.
In later patch, the snd_power_wait() calls will be cleaned up.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20210523090920.15345-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-05-23 11:09:16 +02:00
|
|
|
|
|
|
|
|
|
2005-06-29 19:31:06 +02:00
|
|
|
|
2021-05-23 11:09:19 +02:00
|
|
|
|
ALSA: control: Track in-flight control read/write/tlv accesses
Although the power state check is performed in various places (e.g. at
the entrance of quite a few ioctls), there can be still some pending
tasks that already went into the ioctl handler or other ops, and those
may access the hardware even after the power state check. For
example, kcontrol access ioctl paths that call info/get/put callbacks
may update the hardware registers. If a system wants to assure the
free from such hw access (like the case of PCI rescan feature we're
going to implement in future), this situation must be avoided, and we
have to sync such in-flight tasks finishing beforehand.
For that purpose, this patch introduces a few new things in core code:
- A refcount, power_ref, and a wait queue, power_ref_sleep, to the
card object
- A few new helpers, snd_power_ref(), snd_power_unref(),
snd_power_ref_and_wait(), and snd_power_sync_ref()
In the code paths that call kctl info/read/write/tlv ops, we check the
power state with the newly introduced snd_power_ref_and_wait(). This
function also takes the card.power_ref refcount for tracking this
in-flight task. Once after the access finishes, snd_power_unref() is
called to released the refcount in return. So the driver can sync via
snd_power_sync_ref() assuring that all in-flight tasks have been
finished.
As of this patch, snd_power_sync_ref() is called only at
snd_card_disconnect(), but it'll be used in other places in future.
Note that atomic_t is used for power_ref intentionally instead of
refcount_t. It's because of the design of refcount_t type; refcount_t
cannot be zero-based, and it cannot do dec_and_test() call for
multiple times, hence it's not suitable for our purpose.
Also, this patch changes snd_power_wait() to accept only
SNDRV_CTL_POWER_D0, which is the only value that makes sense.
In later patch, the snd_power_wait() calls will be cleaned up.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20210523090920.15345-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-05-23 11:09:16 +02:00
|
|
|
|
2005-06-29 19:31:06 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2021-05-23 11:09:19 +02:00
|
|
|
|
ALSA: control: Track in-flight control read/write/tlv accesses
Although the power state check is performed in various places (e.g. at
the entrance of quite a few ioctls), there can be still some pending
tasks that already went into the ioctl handler or other ops, and those
may access the hardware even after the power state check. For
example, kcontrol access ioctl paths that call info/get/put callbacks
may update the hardware registers. If a system wants to assure the
free from such hw access (like the case of PCI rescan feature we're
going to implement in future), this situation must be avoided, and we
have to sync such in-flight tasks finishing beforehand.
For that purpose, this patch introduces a few new things in core code:
- A refcount, power_ref, and a wait queue, power_ref_sleep, to the
card object
- A few new helpers, snd_power_ref(), snd_power_unref(),
snd_power_ref_and_wait(), and snd_power_sync_ref()
In the code paths that call kctl info/read/write/tlv ops, we check the
power state with the newly introduced snd_power_ref_and_wait(). This
function also takes the card.power_ref refcount for tracking this
in-flight task. Once after the access finishes, snd_power_unref() is
called to released the refcount in return. So the driver can sync via
snd_power_sync_ref() assuring that all in-flight tasks have been
finished.
As of this patch, snd_power_sync_ref() is called only at
snd_card_disconnect(), but it'll be used in other places in future.
Note that atomic_t is used for power_ref intentionally instead of
refcount_t. It's because of the design of refcount_t type; refcount_t
cannot be zero-based, and it cannot do dec_and_test() call for
multiple times, hence it's not suitable for our purpose.
Also, this patch changes snd_power_wait() to accept only
SNDRV_CTL_POWER_D0, which is the only value that makes sense.
In later patch, the snd_power_wait() calls will be cleaned up.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20210523090920.15345-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-05-23 11:09:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-10-16 13:24:52 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-17 13:51:18 +01:00
|
|
|
|
2005-11-20 14:03:48 +01:00
|
|
|
|
2005-11-20 14:05:49 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-03-28 01:56:41 -08:00
|
|
|
|
2005-11-20 14:06:59 +01:00
|
|
|
|
2006-08-07 22:19:37 -07:00
|
|
|
|
2012-10-16 13:05:59 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-01-26 12:40:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-29 11:46:11 +01:00
|
|
|
|
2007-01-26 12:40:31 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-10-24 17:05:03 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-06-20 19:56:34 +02:00
|
|
|
|
ALSA: jack: implement software jack injection via debugfs
This change adds audio jack injection feature through debugfs, with
this feature, we could validate alsa userspace changes by injecting
plugin or plugout events to the non-phantom audio jacks.
With this change, the sound core will build the folders
$debugfs_mount_dir/sound/cardN if SND_DEBUG and DEBUG_FS are enabled.
And if users also enable the SND_JACK_INJECTION_DEBUG, the jack
injection nodes will be built in the folder cardN like below:
$tree $debugfs_mount_dir/sound
$debugfs_mount_dir/sound
├── card0
│ ├── HDMI_DP_pcm_10_Jack
│ │ ├── jackin_inject
│ │ ├── kctl_id
│ │ ├── mask_bits
│ │ ├── status
│ │ ├── sw_inject_enable
│ │ └── type
...
│ └── HDMI_DP_pcm_9_Jack
│ ├── jackin_inject
│ ├── kctl_id
│ ├── mask_bits
│ ├── status
│ ├── sw_inject_enable
│ └── type
└── card1
├── HDMI_DP_pcm_5_Jack
│ ├── jackin_inject
│ ├── kctl_id
│ ├── mask_bits
│ ├── status
│ ├── sw_inject_enable
│ └── type
...
├── Headphone_Jack
│ ├── jackin_inject
│ ├── kctl_id
│ ├── mask_bits
│ ├── status
│ ├── sw_inject_enable
│ └── type
└── Headset_Mic_Jack
├── jackin_inject
├── kctl_id
├── mask_bits
├── status
├── sw_inject_enable
└── type
The nodes kctl_id, mask_bits, status and type are read-only, users
could check jack or jack_kctl's information through them.
The nodes sw_inject_enable and jackin_inject are directly used for
injection. The sw_inject_enable is read-write, users could check if
software injection is enabled or not on this jack, and users could
echo 1 or 0 to enable or disable software injection on this jack. Once
the injection is enabled, the jack will not change by hardware events
anymore, once the injection is disabled, the jack will restore the
last reported hardware events to the jack. The jackin_inject is
write-only, if the injection is enabled, users could echo 1 or 0 to
this node to inject plugin or plugout events to this jack.
For the detailed usage information on these nodes, please refer to
Documentation/sound/designs/jack-injection.rst.
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20210127085639.74954-2-hui.wang@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-01-27 16:56:39 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-16 18:02:44 +02:00
|
|
|
|
2015-01-29 21:32:47 +01:00
|
|
|
|
2015-01-30 08:34:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-20 14:06:59 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-11-20 14:03:48 +01:00
|
|
|
|
2014-02-04 13:51:45 +01:00
|
|
|
|
2005-11-17 13:51:18 +01:00
|
|
|
|
2005-11-20 14:06:59 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-14 18:31:35 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-05-15 19:49:05 +02:00
|
|
|
|
2017-05-12 11:44:03 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-17 13:51:18 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-01-29 12:51:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ALSA: core: Add managed card creation
As a second step for preliminary to widen the devres usages among
sound drivers, this patch adds a new ALSA core API function,
snd_devm_card_new(), to create a snd_card object via devres.
When a card object is created by this new function, snd_card_free() is
called automatically and the card object resource gets released at the
device unbinding time.
However, the story isn't that simple. A caveat is that we have to
call snd_card_free() at the very first of the whole resource release
procedure, in order to assure that the all exposed devices on
user-space are deleted and sync with processes accessing those devices
before releasing resources.
For achieving it, snd_card_register() adds a new devres action to
trigger snd_card_free() automatically when the given card object is a
"managed" one. Since usually snd_card_register() is the last step of
the initialization, this should work in most cases.
With all these tricks, some drivers can get rid of the whole driver
remove callback code.
About a bit of implementation details: the patch adds two new flags to
snd_card object: managed and releasing. The former indicates that the
object was created via snd_devm_card_new(), and the latter is used for
avoiding the double-free of snd_card_free() calls. Both flags are
fairly internal and likely uninteresting to normal users.
Link: https://lore.kernel.org/r/20210715075941.23332-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-07-15 09:58:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-29 12:51:12 +01:00
|
|
|
|
2023-02-07 20:19:05 +01:00
|
|
|
|
ALSA: add snd_card_disconnect_sync()
In case of user unbind ALSA driver during playing back / capturing,
each driver needs to stop and remove it correctly. One note here is
that we can't cancel from remove function in such case, because
unbind operation doesn't check return value from remove function.
So, we *must* stop and remove in this case.
For this purpose, we need to sync (= wait) until the all top-level
operations are canceled at remove function.
For example, snd_card_free() processes the disconnection procedure at
first, then waits for the completion. That's how the hot-unplug works
safely. It's implemented, at least, in the top-level driver removal.
Now for the lower level driver, we need a similar strategy. Notify to
the toplevel for hot-unplug (disconnect in ALSA), and sync with the
stop operation, then continue the rest of its own remove procedure.
This patch adds snd_card_disconnect_sync(), and driver can use it from
remove function.
Note: the "lower level" driver here refers to a middle layer driver
(e.g. ASoC components) that can be unbound freely during operation.
Most of legacy ALSA helper drivers don't have such a problem because
they can't be unbound.
Note#2: snd_card_disconnect_sync() merely calls snd_card_disconnect()
and syncs with closing all pending files. It takes only the files
opened by user-space into account, and doesn't care about object
refcounts. (The latter is handled by snd_card_free() completion call,
BTW.) Also, the function doesn't free resources by itself.
Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-10-11 06:36:13 +00:00
|
|
|
|
2023-02-07 20:19:07 +01:00
|
|
|
|
2023-02-07 20:19:06 +01:00
|
|
|
|
2022-04-12 11:31:40 +02:00
|
|
|
|
2009-06-02 12:02:38 +02:00
|
|
|
|
2005-11-17 13:51:18 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-01-30 12:27:43 +01:00
|
|
|
|
|
|
|
|
|
2005-11-17 13:51:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-16 18:18:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2026-06-04 01:48:13 -03:00
|
|
|
|
|
|
|
|
|
2008-04-01 15:33:22 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-29 15:13:33 +01:00
|
|
|
|
2020-01-03 09:16:19 +01:00
|
|
|
|
2005-11-17 13:51:18 +01:00
|
|
|
|
|
|
|
|
|
2015-02-27 18:01:22 +01:00
|
|
|
|
|
|
|
|
|
2014-02-04 11:36:11 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-23 22:45:06 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-15 09:58:25 +02:00
|
|
|
|
2005-08-23 22:45:06 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-10-11 17:28:58 +02:00
|
|
|
|
2005-10-10 11:56:31 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-07 09:37:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-08 17:18:08 +02:00
|
|
|
|
2008-11-07 09:37:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-04 17:02:59 -05:00
|
|
|
|
|
|
|
|
|
2008-11-07 09:37:22 +01:00
|
|
|
|
2013-03-04 17:02:59 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-06 12:05:21 -08:00
|
|
|
|
2013-03-04 17:02:59 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-12 11:44:03 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-11-24 15:34:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-30 17:27:45 +01:00
|
|
|
|
2006-11-24 15:34:06 +01:00
|
|
|
|
2008-05-20 12:15:15 +02:00
|
|
|
|
2006-11-24 15:34:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-30 17:27:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-11-24 15:34:06 +01:00
|
|
|
|
2008-05-20 12:15:15 +02:00
|
|
|
|
2006-11-24 15:34:06 +01:00
|
|
|
|
|
|
|
|
|
2009-01-30 17:27:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-25 10:54:07 +01:00
|
|
|
|
2006-11-24 15:34:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-30 17:27:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-25 10:54:07 +01:00
|
|
|
|
2006-11-24 15:34:06 +01:00
|
|
|
|
|
|
|
|
|
2014-02-28 15:41:31 -08:00
|
|
|
|
2006-11-24 15:34:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-14 09:16:52 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-28 15:41:31 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-30 17:10:58 +08:00
|
|
|
|
2006-11-24 15:34:06 +01:00
|
|
|
|
2022-07-28 14:59:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
