mirrors
/
linux-stable
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
1
0
Fork 0
Code Issues Releases Wiki Activity

ASoC: doc: dapm: fix and improve section "Registering DAPM controls" 

Extend the first paragraph to mention the {,num_}dapm_routes fields just
like the widget conterparts. Mention the route fields also in the code
example. Fix "at build time", this really means "at probe time".

Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://lore.kernel.org/r/20240426-dapm-docs-v2-9-87b07547eb5b@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This commit is contained in:
Luca Ceresoli 2024-04-26 18:56:42 +02:00 committed by Mark Brown
parent 36de8c0e26
commit d40e821944
No known key found for this signature in database
GPG Key ID: 24D68B725D5487D0
1 changed files with 14 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
Documentation/sound/soc/dapm.rst
View File

@ -253,12 +253,17 @@ This can be used to merge two signal paths together in software.
Registering DAPM controls
=========================
In many cases the DAPM widgets implemented statically in a ``static const
struct snd_soc_dapm_widget`` array and the routes connecting them in a
``static const struct snd_soc_dapm_route`` array in a codec driver, and
simply declared via the ``dapm_widgets`` and ``num_dapm_widgets`` fields of
the ``struct snd_soc_component_driver`` so the driver registration will
take care of populating them::
In many cases the DAPM widgets are implemented statically in a ``static
const struct snd_soc_dapm_widget`` array in a codec driver, and simply
declared via the ``dapm_widgets`` and ``num_dapm_widgets`` fields of the
``struct snd_soc_component_driver``.
Similarly, routes connecting them are implemented statically in a ``static
const struct snd_soc_dapm_route`` array and declared via the
``dapm_routes`` and ``num_dapm_routes`` fields of the same struct.
With the above declared, the driver registration will take care of
populating them::
static const struct snd_soc_dapm_widget wm2000_dapm_widgets[] = {
SND_SOC_DAPM_OUTPUT("SPKN"),
@ -277,11 +282,13 @@ take care of populating them::
...
.dapm_widgets = wm2000_dapm_widgets,
.num_dapm_widgets = ARRAY_SIZE(wm2000_dapm_widgets),
.dapm_routes = wm2000_audio_map,
.num_dapm_routes = ARRAY_SIZE(wm2000_audio_map),
...
};
In more complex cases the list of DAPM widgets and/or routes can be only
known at build time. This happens for example when a driver supports
known at probe time. This happens for example when a driver supports
different models having a different set of features. In those cases
separate widgets and routes arrays implementing the case-specific features
can be registered programmatically by calling snd_soc_dapm_new_controls()