summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLuca Ceresoli <luca.ceresoli@bootlin.com>2024-04-26 18:56:42 +0200
committerMark Brown <broonie@kernel.org>2024-04-29 23:49:34 +0900
commitd40e82194423c9d058bdeff863373b7da9f7045b (patch)
tree72a22a0c36a67336406d326b25315bc981ad2fbb
parent36de8c0e26793beeda1d6a7592f44b4551271469 (diff)
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>
-rw-r--r--Documentation/sound/soc/dapm.rst21
1 files changed, 14 insertions, 7 deletions
diff --git a/Documentation/sound/soc/dapm.rst b/Documentation/sound/soc/dapm.rst
index 57d96a39f124..50f908f4e8ed 100644
--- a/Documentation/sound/soc/dapm.rst
+++ b/Documentation/sound/soc/dapm.rst
@@ -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()