[PATCH] ASoC: Intel: sof_sdw_cs_amp: Connect outputs to a speaker widget

[PATCH] ASoC: Intel: sof_sdw_cs_amp: Connect outputs to a speaker widget

[Richard Fitzgerald]

Hookup the CS35L56 DAPM_OUTPUT widgets to a DAPM_SPK widget so
that there is a complete logical path to a speaker.

There is no particular reason to use multiple speaker widgets.
The CS35L56 are designed to work together as a set so they have
all been connected to a single speaker widget.

Instead of a hardcoded list of codec widget names, the code walks
through all the codecs on the dailink and for every cs35l56 it uses
its name prefix to construct the source end of the route. This adds
a small amount of overhead during probe but has the benefit that it
isn't dependent on every system using the same prefixes.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
---
 sound/soc/intel/boards/sof_sdw_cs_amp.c | 30 +++++++++++++++++++++++--
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/sound/soc/intel/boards/sof_sdw_cs_amp.c b/sound/soc/intel/boards/sof_sdw_cs_amp.c
index 98f6546f484b..f88c01552a92 100644
--- a/sound/soc/intel/boards/sof_sdw_cs_amp.c
+++ b/sound/soc/intel/boards/sof_sdw_cs_amp.c
@@ -9,15 +9,24 @@
 #include <linux/errno.h>
 #include <sound/soc.h>
 #include <sound/soc-acpi.h>
+#include <sound/soc-dai.h>
 #include "sof_sdw_common.h"
 
 #define CODEC_NAME_SIZE	8
 
+static const struct snd_soc_dapm_widget sof_widgets[] = {
+	SND_SOC_DAPM_SPK("Speakers", NULL),
+};
+
 static int cs_spk_init(struct snd_soc_pcm_runtime *rtd)
 {
 	const char *dai_name = rtd->dai_link->codecs->dai_name;
 	struct snd_soc_card *card = rtd->card;
 	char codec_name[CODEC_NAME_SIZE];
+	char widget_name[16];
+	struct snd_soc_dapm_route route = { "Speakers", NULL, widget_name };
+	struct snd_soc_dai *codec_dai;
+	int i, ret;
 
 	snprintf(codec_name, CODEC_NAME_SIZE, "%s", dai_name);
 	card->components = devm_kasprintf(card->dev, GFP_KERNEL,
@@ -26,17 +35,34 @@ static int cs_spk_init(struct snd_soc_pcm_runtime *rtd)
 	if (!card->components)
 		return -ENOMEM;
 
+	ret = snd_soc_dapm_new_controls(&card->dapm, sof_widgets,
+					ARRAY_SIZE(sof_widgets));
+	if (ret) {
+		dev_err(card->dev, "widgets addition failed: %d\n", ret);
+		return ret;
+	}
+
+	for_each_rtd_codec_dais(rtd, i, codec_dai) {
+		if (!strstr(codec_dai->name, "cs35l56"))
+			continue;
+
+		snprintf(widget_name, sizeof(widget_name), "%s SPK",
+			 codec_dai->component->name_prefix);
+		ret = snd_soc_dapm_add_routes(&card->dapm, &route, 1);
+		if (ret)
+			return ret;
+	}
+
 	return 0;
 }
 
-
 int sof_sdw_cs_amp_init(struct snd_soc_card *card,
 			const struct snd_soc_acpi_link_adr *link,
 			struct snd_soc_dai_link *dai_links,
 			struct sof_sdw_codec_info *info,
 			bool playback)
 {
-	/* Count amp number and do init on playback link only. */
+	/* Do init on playback link only. */
 	if (!playback)
 		return 0;
 
-- 
2.30.2

Re: [PATCH] ASoC: Intel: sof_sdw_cs_amp: Connect outputs to a speaker widget

[Charles Keepax]

On Tue, Dec 05, 2023 at 01:50:01PM +0000, Richard Fitzgerald wrote:
> Hookup the CS35L56 DAPM_OUTPUT widgets to a DAPM_SPK widget so
> that there is a complete logical path to a speaker.
> 
> There is no particular reason to use multiple speaker widgets.
> The CS35L56 are designed to work together as a set so they have
> all been connected to a single speaker widget.
> 
> Instead of a hardcoded list of codec widget names, the code walks
> through all the codecs on the dailink and for every cs35l56 it uses
> its name prefix to construct the source end of the route. This adds
> a small amount of overhead during probe but has the benefit that it
> isn't dependent on every system using the same prefixes.
> 
> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
> ---

Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>

Thanks,
Charles

Re: [PATCH] ASoC: Intel: sof_sdw_cs_amp: Connect outputs to a speaker widget

[Pierre-Louis Bossart]

On 12/5/23 07:50, Richard Fitzgerald wrote:
> Hookup the CS35L56 DAPM_OUTPUT widgets to a DAPM_SPK widget so
> that there is a complete logical path to a speaker.
> 
> There is no particular reason to use multiple speaker widgets.
> The CS35L56 are designed to work together as a set so they have
> all been connected to a single speaker widget.
> 
> Instead of a hardcoded list of codec widget names, the code walks
> through all the codecs on the dailink and for every cs35l56 it uses
> its name prefix to construct the source end of the route. This adds
> a small amount of overhead during probe but has the benefit that it
> isn't dependent on every system using the same prefixes.
> 
> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>

Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>

We should probably do the same thing for sof_sdw_rt_map.c, there's no
good reason to encode rt1316-2 SPOL and rt1318-2 SPOR

Re: [PATCH] ASoC: Intel: sof_sdw_cs_amp: Connect outputs to a speaker widget

[Mark Brown]

On Tue, 05 Dec 2023 13:50:01 +0000, Richard Fitzgerald wrote:
> Hookup the CS35L56 DAPM_OUTPUT widgets to a DAPM_SPK widget so
> that there is a complete logical path to a speaker.
> 
> There is no particular reason to use multiple speaker widgets.
> The CS35L56 are designed to work together as a set so they have
> all been connected to a single speaker widget.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] ASoC: Intel: sof_sdw_cs_amp: Connect outputs to a speaker widget
      commit: 138a4e2a26ec73197e22fe64ee3957b1594eabb3

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark