load topology for each device #5209

bardliao · 2024-10-18T13:32:53Z

Get device information from dai links. load topology for each device.

This should not impact the existing devices.

bardliao · 2024-10-21T05:55:03Z

SOFCI TEST

sound/soc/sof/topology.c

ujfalusi · 2024-11-14T09:34:28Z

sound/soc/sof/topology.c

+		ret = request_firmware(&fw, tplg_files[i].file, scomp->dev);
+		if (ret < 0) {
+			if (i == 0) {
+				dev_dbg(scomp->dev,"Fail back to %s\n", tplg_name);


If it was a topology w/ DMIC then you have dropped the -2ch in a previous loop, you are not going to load the topology you supposed to be loading.

Yes, you are right. I need to restore the original topology name.

ujfalusi · 2024-11-14T09:35:19Z

sound/soc/sof/topology.c

+				tplg_name = strremove(tplg_name, "-2ch");
+			} else if (strstr(file, "-4ch")) {
+				tplg_device = "dmic-4ch";
+				tplg_name = strremove(tplg_name, "-4ch");


why are you dropping the 2ch/4ch from the original name?

Because I would like to load the topology without dmic. For example, sof-hda-generic-2ch.tplg -> sof-hda-generic.tplg or similar.

But the tplg_name is used only for loading the fallback, legacy, monolithic topology, in which case the fragments are not loaded. On a machine which have DMIC, you will load the topology w/o DMIC

Not exactly, tplg_name topology will be also loaded if not all dai links are handled. For example, if the monolithic topology is sof-lnl-rt711-4ch, then sof-lnl-rt711 and sof-lnl-dmic-4ch-id5 will be loaded

right, but if something fails in between and we need to fallback to the monolithic topology then at line 2641 you will have sof-lnl-rt711.tplg instead the correct monolithic sof-lnl-rt711-4ch.tplg, or am I missing something?

right, but if something fails in between and we need to fallback to the monolithic topology then at line 2641 you will have sof-lnl-rt711.tplg instead the correct monolithic sof-lnl-rt711-4ch.tplg, or am I missing something?

Yeah, I will restore the tplg file name when it fails back to the monolithic topology, thanks.

ujfalusi · 2024-11-14T09:39:14Z

sound/soc/sof/topology.c

+			if (strstr(file, "hda-generic")) {
+				tplg_device = "idisp";
+			} else {
+				tplg_device = "sdca-hdmi";


this is HDMI audio using SDW link or HDMI audio using HDA link, but used with SDW machine?

This is the HDMI audio used with SDW codecs. I use different name for different codec interfaces is because that the existing topologies use different PCM id for different codec interfaces. For example, the HDMI PCM ids are 5,6,7 for SDW machines and 3,4,5 for HDA machines.

00-00: Jack Out (*) : : playback 1 00-01: Jack In (*) : : capture 1 00-02: Speaker (*) : : playback 1 00-03: Amp feedback (*) : : capture 1 00-04: Microphone (*) : : capture 1 00-05: HDMI1 (*) : : playback 1 00-06: HDMI2 (*) : : playback 1 00-07: HDMI3 (*) : : playback 1 00-31: Deepbuffer Jack Out (*) : : playback 1

00-00: HDA Analog (*) : : playback 1 : capture 1 00-03: HDMI1 (*) : : playback 1 00-04: HDMI2 (*) : : playback 1 00-05: HDMI3 (*) : : playback 1 00-06: DMIC Raw (*) : : capture 1 00-31: Deepbuffer HDA Analog (*) : : playback 1

ujfalusi · 2024-11-14T09:40:36Z

sound/soc/sof/topology.c

+		} else if (strstr(dai_link->name, "iDisp")) {
+			tplg_dev = TPLG_DEVICE_HDMI;
+			if (strstr(file, "hda-generic")) {
+				tplg_device = "idisp";


If I read the function right, this is not going to be used as the hda-generic will fall under load_default_tplg = true, the HDA dai_link->name is not handled?

load_default_tplg = true means there are still some remaining pcms that are not loaded in the sparated topologies. And we need to load the renamed topology at line 2620.

but can you load the idisp.tplg and the sof-hda-generic.tplg which also contains idisp definitions?

but can you load the idisp.tplg and the sof-hda-generic.tplg which also contains idisp definitions?

No, so we need to make sure there is no idisp in sof-hda-generic.tplg.

ujfalusi · 2024-11-14T09:44:26Z

sound/soc/sof/topology.c

+						     "sdca-%damp", dai_link->num_cpus);
+		} else if (strstr(dai_link->name, "SmartMic")) {
+			tplg_dev = TPLG_DEVICE_SDW_MIC;
+			tplg_device = "sdca-mic";


Here and for the other checks: we need to update this match list every time a new component got introduced to products and we have new tplg fragment?
Is it going to scale?

We need to update this match list when a new dai links got introduced. Given that we didn't update dai links in our machine drivers. I think we will only update the match list occasionally.

ujfalusi · 2024-11-14T09:49:08Z

sound/soc/sof/topology.c

+						    tplg_files[i].device,
+						    tplg_files[i].be_id);
+		dev_dbg(scomp->dev, "Requesting %d %s\n", i, tplg_files[i].file);
+		ret = request_firmware(&fw, tplg_files[i].file, scomp->dev);


the sof_create_ipc_file_profile() will check if the firmware and the topology file (the monolithic one!) is in place.
The means that you always need to have the monolithic tplg and the split components installed, otherwise the profile is rejected and if not fallback IPC version is available then we will fail.

I have a feeling that this split tplg handling has to touch the fw-file-profile.c as well.

Yeah, I am thinking this open, too. My idea is that we don't touch the monolithic topology. I.e. the monolithic topology will coexist with the split topologies. So that sof_create_ipc_file_profile() will still valid.

ujfalusi · 2024-11-14T09:50:29Z

sound/soc/sof/topology.c

+						    "%s/sof-%s-%s-id%d.tplg",
+						    sof_pdata->tplg_filename_prefix, platform,
+						    tplg_files[i].device,
+						    tplg_files[i].be_id);


a clean documentation as commit message and comments to explain clearly the expected file naming and also an update to sof-docs must be done.

Totally agree.

have you thought about the documentation?

I almost forget the document. I will do it next week.

Sorry for the delay. @ujfalusi The sof-docs PR is thesofproject/sof-docs#507

bardliao · 2024-11-20T11:25:08Z

Topology PR: thesofproject/sof#9668. I would like to start with SDCA codecs only. SDCA is more urgent than others. If we can create dai links based on the supported SDCA functions, we don't need to use quirks for enabling/disabling specific dai links.

sound/soc/sof/topology.c

ujfalusi · 2024-12-13T11:07:19Z

sound/soc/sof/topology.c

@@ -2464,15 +2465,180 @@ static const struct snd_soc_tplg_ops sof_dspless_tplg_ops = {
 	.bytes_ext_ops_count = ARRAY_SIZE(sof_dspless_bytes_ext_ops),
 };

+#define MAX_TPLG_NUM 5


Add TPLG_DEVICE_MAX at the end of the enum?

Yes, it would be better.

ujfalusi · 2024-12-13T11:12:40Z

sound/soc/sof/topology.c

+
+static bool is_platform_support_separated_tplg(const char *platform)
+{
+	if (!strcmp(platform, "mtl") || !strcmp(platform, "lnl") || !strcmp(platform, "ptl"))


this is not going to scale... You are already missing ARL...
I would allow this for SOF_IPC4, I guess you handle the case when the topology files are not split, so it should just fallback?

I guess you want to exclude the sof-hda on top of platform, right?
if !ipc4 || hda -> false ?
But this includes I2S machines also... Not sure what rule you want to make here.

My first thought is to only list the platforms that we already have the topology support. And "HDA" is one of the "platform" because we use sof-hda-generic.tplg for all platforms. Yeah, we can remove this check and fallback if the driver doesn't find the topology files.

ujfalusi · 2024-12-13T11:23:41Z

sound/soc/sof/topology.c

+		} else if (strstr(dai_link->name, "SmartAmp")) {
+			tplg_dev = TPLG_DEVICE_SDW_AMP;
+			tplg_device = devm_kasprintf(sdev->dev, GFP_KERNEL,
+						     "sdca-%damp", dai_link->num_cpus);


can there be multiple SmartAmp link? You only going to record the first one. The naming of the device is also interesting, it is postfixed with a number of CPU dais?

We don't support multiple SmartAmp link in the machine driver. And, yes, postfixing with a number of CPU dais is intentional. We need to set NUM_SDW_AMP_LINKS in the topology.

ujfalusi · 2024-12-13T11:28:39Z

sound/soc/sof/topology.c

+						    "%s/sof-%s-%s-id%d.tplg",
+						    sof_pdata->tplg_filename_prefix, platform,
+						    tplg_files[i].device,
+						    tplg_files[i].be_id);


have you thought about the documentation?

ujfalusi · 2024-12-13T11:45:34Z

sound/soc/sof/topology.c

+	TPLG_DEVICE_SDW_JACK,
+	TPLG_DEVICE_SDW_AMP,
+	TPLG_DEVICE_SDW_MIC,
+	TPLG_DEVICE_HOST_DMIC,


This is awkwardly named, I think you meant INTEL_DMIC (conencted to PCH-DMIC)?

I will change it to TPLG_DEVICE_PCH_DMIC, thanks

ujfalusi · 2024-12-13T11:51:19Z

sound/soc/sof/topology.c

+			tplg_dev = TPLG_DEVICE_HOST_DMIC;
+		} else if (strstr(dai_link->name, "iDisp")) {
+			tplg_dev = TPLG_DEVICE_HDMI;
+			tplg_device = "sdca-hdmi";


I know that you have excluded generic HDA, but things might fall through the cracks and picks this as HDMI where the PCM device id range is not 5,6,7. Which I suppose this fragment will provide.

How this naming going to scale with display audio serviced by SDW?

I'm not sure how this can be handled, but if we let HDA generic into \this logic, it is going to fail.

I added the be_id in the topology name, so that the PCM device id can be any number.

ujfalusi · 2024-12-13T11:54:51Z

sound/soc/sof/topology.c

+				goto legacy_tplg;
+			}
+
+			dev_err(scomp->dev, "error: tplg request firmware %s failed err: %d\n",


Please don't use 'error:' in new prints.

ujfalusi · 2024-12-13T11:58:50Z

sound/soc/sof/topology.c

+			return -ENOMEM;
+
+		dev_dbg(scomp->dev, "Requesting %d %s\n", i, tplg_files[i].file);
+		ret = request_firmware(&fw, tplg_files[i].file, scomp->dev);


firmware_request_nowarn() to handle the fallback in case the fragmented tplg is not present, but what will happen if you load two fragment thn the third is missing and try to load the monolithic over it?

I'm sure that this is going to happen.

and the original name is altered, the -2/4ch is dropped, so we are not going to load the right tplg in some cases.

firmware_request_nowarn() to handle the fallback in case the fragmented tplg is not present, but what will happen if you load two fragment thn the third is missing and try to load the monolithic over it?

It will return error if the second or later topology is not present. My idea is that if we can't find the first fragmented topology, it means we don't have the required version of topologies, then we need to fall back to use the original topology. However, if we find the first fragmented topology, it means we use the new version of topology, and there should be something wrong if we don't find any required fragmented topology.

and the original name is altered, the -2/4ch is dropped, so we are not going to load the right tplg in some cases.

I will restore the file name in this case.

ujfalusi · 2024-12-13T12:00:13Z

sound/soc/sof/topology.c

+
+	for (i = 0; i < tplg_num; i++) {
+		tplg_files[i].file = devm_kasprintf(sdev->dev, GFP_KERNEL,
+						    "%s/sof-%s-%s-id%d.tplg",


Another question: can a sof-sdca-jack.tplg work on all platforms, do we really need the mtl/lnl/ptl/arl/etc variants?

Good questions. We set 'PLATFORM' in the topology, but we don't set any variables for SDW. So, I think we can remove the platform name for the SDW topologies. It will be easier to implement the topologies.

bardliao · 2025-01-16T09:19:00Z

The sof-docs PR is thesofproject/sof-docs#507 and topology PR is thesofproject/sof#9668. @ujfalusi @ranj063 @lgirdwood Could you review? Thanks.

ujfalusi

@bardliao, I will continue on Monday, sorry for the delay.

ujfalusi · 2025-02-07T13:50:59Z

sound/soc/sof/topology.c

+};
+
+/* The code is from https://stackoverflow.com/questions/47116974/remove-a-substring-from-a-string-in-c */
+static char *strremove(char *str, const char *sub)


I'm not sure if we want code from 'shady' places in kernel ;)

On the second thought, the current PR only supports split topologies when all devices are covered by the split topologies. There is no needed to change the original tplg file name. And we don't need *strremove() in the commit.

ujfalusi · 2025-02-07T13:56:05Z

sound/soc/sof/topology.c


 	dev_dbg(scomp->dev, "loading topology:%s\n", file);

-	ret = request_firmware(&fw, file, scomp->dev);
+	tplg_name = devm_kasprintf(sdev->dev, GFP_KERNEL, "%s", file);


is this needs to be resource managed?

ujfalusi · 2025-02-07T13:59:36Z

sound/soc/sof/topology.c

+	if (sdev->pdata->ipc_type == SOF_IPC_TYPE_3)
+		goto legacy_tplg;
+
+	ret = sscanf(sof_pdata->tplg_filename, "sof-%3s-*.tplg", platform);


So we must always have a monolithic topology present in filesystem? During probe we check for existence of the topology file in sof_test_topology_file() and we will fail if it is missing.

Yes, we will create the monolithic topology. It is also for the old kernel that doesn't support split topologies.

@bardliao I have a couple of fundamental problems with your solution.

We start off as if there's only 1 topology file for each machine and then you come here in this function and decide thats not correct and then figure out what all sub-topologies to load. What does it mean "user will create topology for single device...". Its more like the user will create multiple generic mini topologies that are applicable across platforms isnt it?

Secondly, this is very Soundwire-specific isnt it? Can we make it a bit more generic so that it applies to all machines, SDW, I2S, HDA etc? We can have a coarse-grained split based on DAI types i.e SDW/I2S/HDA + HDMI + DMIC and a fine-grained split for the first part based onthe disco table for the SDW bits. This way we can do this change in 2 steps, first the split by DAI types and then isolate the SDW disco-specific split as a second step so it makes it more intuitive for everyone to understand.

ujfalusi · 2025-02-07T14:00:22Z

sound/soc/sof/topology.c

 	const struct firmware *fw;
+	bool load_default_tplg = false;
+	unsigned long tplg_mask = 0;
+	char platform[4];


"tgl-h" needs 6 char space...

But the PLATFORM name is "tgl" in the topology.

right, but this is a generic code, you cannot assume that every vendor's every topology family will use three letters.

no magic numbers like 4 please

ujfalusi · 2025-02-07T14:03:02Z

sound/soc/sof/topology.c

 int snd_sof_load_topology(struct snd_soc_component *scomp, const char *file)
 {
 	struct snd_sof_dev *sdev = snd_soc_component_get_drvdata(scomp);
+	struct topology_file tplg_files[TPLG_DEVICE_MAX];


We can ever have 1 instance providing a function? no two jack/amp/mic/dmic/hdmi ? only ever one from each?

think about karaoke devices with multiple jacks/mics for example.

The idea is to have a topology for a function. Like we have 3 hdmi pcms, but we only have 1 hdmi topology.

sound/soc/sof/card-tplg-ops.c

ranj063 · 2025-02-18T17:45:49Z

sound/soc/sof/topology.c

@@ -2321,7 +2322,7 @@ static const struct snd_soc_tplg_ops sof_tplg_ops = {
 	.link_unload	= sof_link_unload,

 	/* completion - called at completion of firmware loading */
-	.complete	= sof_complete,
+	/* complete will be added in the last tplg ops */


what do you mean by the last topology here?

The latest tplg file that we load.

Can you be a bit more outspoken with:

/* completion - called at completion of firmware loading It is going to be set to sof_complete before the last topology fragment is loaded to finalize the topology loading. */ .complete = NULL,

ranj063 · 2025-02-18T17:49:21Z

sound/soc/sof/topology.c

+		goto legacy_tplg;
+
+	for (i = 0; i < tplg_num; i++) {
+		dev_dbg(scomp->dev, "Requesting %d %s\n", i, tplg_files[i]);


I think it makes better sense to move this down below just before loading the topology

Hmm, but I need to know which file are needed. We will not know the file name if the first tplg file is not in the device.

ranj063 · 2025-02-18T17:50:06Z

sound/soc/sof/topology.c

+		if (ret < 0) {
+			if (i == 0) {
+				dev_dbg(scomp->dev, "Fail back to %s\n", file);
+				kfree(tplg_files[i]);


why are we freeing this here, this function doesnt seem to allocate it?

tplg_files[] are allocated in card_ops[i].get_tplg_files(). Moved after the out: label and added a comment to describe where they are allocated.

ranj063 · 2025-02-18T17:50:15Z

sound/soc/sof/topology.c

+
+			dev_err(scomp->dev, "tplg request firmware %s failed err: %d\n",
+				tplg_files[i], ret);
+			kfree(tplg_files[i]);


ranj063 · 2025-02-18T17:50:21Z

sound/soc/sof/topology.c

+			kfree(tplg_files[i]);
+			goto out;
+		}
+		kfree(tplg_files[i]);


ranj063 · 2025-02-18T17:52:40Z

sound/soc/sof/topology.c

+
+		/* set complete = sof_complete if it is the last topology */
+		if (i == tplg_num - 1)
+			sof_tplg_ops.complete = sof_complete;


why should we restrict complete to only the last sub topology? All we do there is update the IPC structures, set the pipeline widget etc. Can we make this independent for each sub-tooplogy?

All controls/widgets are added in the sdev lists and they will be handled. We need to split them if we want to handle them separately. Consider the same *scomp is passed to the .complete ops, I don't know how to make it independent for each sub-tooplogy. And actually, I don't get the benefit of make it independently.

instead of setting the complete op why not just simply call sof_complete() here after successfully loading the last topology?

ranj063 · 2025-02-18T17:53:09Z

sound/soc/sof/topology.c

+		release_firmware(fw);
+
+		if (ret < 0) {
+			dev_err(scomp->dev, "tplg component load failed %d\n", ret);


the return value will be printed anyway, can we print the name of the topology that failed here?

ranj063 · 2025-02-18T17:56:32Z

sound/soc/sof/topology.c

+		}
+	}
+	/* Load topology successfully, goto out */
+	goto out;


I think this part below should be condensed into the loop. Start with tplg_num = 1. Set the tplg_files[0] = file to begin with. Then you can remove the whole block below.

Good suggestion, done

ranj063 · 2025-02-18T17:58:38Z

sound/soc/sof/card-tplg-ops.c

@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause)


@bardliao an alternative thought. Can we move this to the machine driver? I think it makes sense for this code to coexist along with the machine info and dailinks there.

I thought about it. However, the topology stuff is more like belong to component level instead of card level. Besides, we need the *sof_pdata data to construct the tplg file name.

you've got tplg file name is available also in struct snd_soc_acpi_mach. I dont think you really need sof_pdata for this

I thought about it. However, the topology stuff is more like belong to component level instead of card level. Besides, we need the *sof_pdata data to construct the tplg file name.

I agree with topology stuff belonging to component but this has nothing to do with the topology stuff but rather the machine level stuff ie whether there's a mic, a speaker a dmic etc no?

@ranj063 I moved the ops to sound/soc/intel/common/, and set the ops in each acpi_mach that needs it. I don't set the ops in sof_sdw.c because I can't access the same acpi_mach pointer in sof_sdw.c and SOF driver. The acpi_mach data is copied to the platform device not the pointer.

ranj063 · 2025-02-18T18:02:49Z

@bardliao I still have some fundamental issues with this approach:

The card_tplg_ops seems like it should belong in the machine driver code and not the SOF core.
We end up parsing all the sub-topologies and storing all the info in sdev with no distinction that they come from different topologies.
Error handling: If a sub-topology load fails, you dont seem to unload the first few successfully loaded topologies

ranj063 · 2025-02-18T18:04:08Z

sound/soc/sof/topology.c

+
+		if (ret < 0) {
+			dev_err(scomp->dev, "tplg component load failed %d\n", ret);
+			return ret;


this is incomplete. With a monolithic topology, an error would make sure to remove any successfully objects during topology loading. But with your approach, you leave the sub-topologies loaded

Added snd_soc_tplg_component_remove()

bardliao · 2025-02-19T09:50:03Z

@bardliao I still have some fundamental issues with this approach:

The card_tplg_ops seems like it should belong in the machine driver code and not the SOF core.

IMHO, the whole topology stuff belongs to the component level instead of the card level. That's why it is in the SOF core.

We end up parsing all the sub-topologies and storing all the info in sdev with no distinction that they come from different topologies.

Yes, my point is that we just put the widgets in different topology files, but they all belong to the same audio system. IOW, they all work together no matter where they are from. I.e. The outcome should be identical no matter we load a monolithic topology or some sub-topologies.

Error handling: If a sub-topology load fails, you dont seem to unload the first few successfully loaded topologies

Yes, handled in the updated code.

ujfalusi

@bardliao, I really like this version much better!
Few comments inside.

ujfalusi · 2025-02-21T12:46:28Z

sound/soc/sof/topology.c

@@ -2321,7 +2322,7 @@ static const struct snd_soc_tplg_ops sof_tplg_ops = {
 	.link_unload	= sof_link_unload,

 	/* completion - called at completion of firmware loading */
-	.complete	= sof_complete,
+	/* complete will be added in the last tplg ops */


Can you be a bit more outspoken with:

/* completion - called at completion of firmware loading It is going to be set to sof_complete before the last topology fragment is loaded to finalize the topology loading. */ .complete = NULL,

ujfalusi · 2025-02-21T12:49:02Z

sound/soc/sof/topology.h

+struct card_tplg_ops {
+	const char *card_name;
+	int (*get_tplg_files)(struct snd_soc_component *scomp, const char *file,
+			      const char ***tplg_files);


The return value must be documented, it is far from obvious from this that it returns -ERRNO or the number of files placed in tplg_files array.
Is 0 valid return value?

ujfalusi · 2025-02-21T12:53:00Z

sound/soc/sof/topology.c

+	for (i = 0; i < ARRAY_SIZE(card_ops); i++) {
+		if (!strcmp(scomp->card->name, card_ops[i].card_name)) {
+			ret = card_ops[i].get_tplg_files(scomp, file, &tplg_files);
+			if (ret < 0)


you can use the file_num directly, but I would rename the *_num to *_cnt, for me the _num is more like pointing to a specific index and here we have count.
or num_files.

you can as well just get away with using the single num_files or tplg_cnt

I use tplg_cnt and file_cnt separately because the tplg_cnt can be changed when we fail back to the original topology. And we need to free the file_cnt number of tplg_files[]

ujfalusi · 2025-02-21T13:03:43Z

sound/soc/sof/topology.c

@@ -2476,6 +2476,10 @@ static const struct snd_soc_tplg_ops sof_dspless_tplg_ops = {
 };

 static const struct card_tplg_ops card_ops[] = {
+	{
+		.card_name = "sof-soundwire",


sof-soundwire is kind of reserved as "INTEL"-sof-soundwire, right? Can we add comment to spell this out?

ujfalusi · 2025-02-21T13:11:42Z

sound/soc/sof/card-tplg-ops.c

+
+#define SOF_INTEL_PLATFORM_NAME_MAX 4
+
+int get_sof_sdw_tplg_files(struct snd_soc_component *scomp, const char *file,


add intel in the function name, we only handle SOF_INTEL_PLATFORM_NAME_MAX long platform names.

ujfalusi · 2025-02-21T13:13:33Z

sound/soc/sof/card-tplg-ops.c

+	TPLG_DEVICE_SDCA_JACK,
+	TPLG_DEVICE_SDCA_AMP,
+	TPLG_DEVICE_SDCA_MIC,
+	TPLG_DEVICE_PCH_DMIC,


TPLG_DEVICE_INTEL_PCH_DMIC
or
TPLG_DEVICE_SOC_DMIC

ujfalusi · 2025-02-21T13:18:57Z

sound/soc/sof/topology.h

+ */
+
+#ifndef __SOUND_SOC_SOF_TOPOLOGY_H
+#define __SOUND_SOC_SOF_TOPOLOGY_H


I would rather create card-tplg-ops.h instead.

We might (might) be able to extend this to be used by the fw-file-profile.c and cut the reliance on the monolithic topology file even if we only expect to use a generic one.

But, but, I guess we can create a generic sof--sdca-full-card.tplg and use this single one for all sdca setups...?

Currently, we always use single topology file to describe the widgets. We could split the topology into several sub-topologies and the sub-topologies can be used across cards. Then we can reuse those sub-topologies in enabling new products. The sub-topoloy name varies between audio configs. Add a get_tplg_files ops to get those names dynamically. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>

ranj063

@bardliao this looks a lot more intuitive. Thanks! Just a few more comments

ranj063 · 2025-02-21T15:22:38Z

sound/soc/intel/common/soc-acpi-intel-get-tplg.c

+	if (ret != 1)
+		return 0;
+
+	pr_err("bard: %s plarform: %s\n", card->name, platform);


ranj063 · 2025-02-21T15:25:12Z

sound/soc/intel/common/soc-acpi-intel-get-tplg.c

+		} else {
+			/* The dai link is not supported by sperated tplg yet */
+			dev_dbg(card->dev,
+				"dai_link %s is not supported by sperated tplg yet\n",


typo seperated both lines but do we need the dbg statement at all?

Yes, it can remind us what dai links are still not supported by separated tplg.

ranj063 · 2025-02-21T15:29:31Z

sound/soc/sof/topology.c

+out:
+	/* Free tplg_files[] which are allocated by card_ops[i].get_tplg_files() */
+	for (i = 0; i < file_cnt; i++)
+		kfree(tplg_files[i]);


This still looks awkward to free here. Why not use devm to allocate memory in the get_tplg_files op so that when the machine driver is removed due to this error, it will get freed automatically?

ranj063 · 2025-02-21T15:31:11Z

sound/soc/intel/common/soc-acpi-intel-get-tplg.c

+	pr_err("bard: %s plarform: %s\n", card->name, platform);
+
+	for_each_card_prelinks(card, i, dai_link) {
+		char *tplg_device;


maybe change this to tplg_device_name or tplg_dev_name so that people dont confused why there's a tplg_dev and tplg_device

ranj063 · 2025-02-21T15:33:16Z

sound/soc/intel/common/soc-acpi-intel-get-tplg.c

+
+	ret = sscanf(mach->sof_tplg_filename, "sof-%3s-*.tplg", platform);
+	if (ret != 1)
+		return 0;


isnt this as error? If not, maybe you can change the return type of this function to uint so that it is explicit

Yes, it is an error. Changed the return value and added a trace.

ranj063 · 2025-02-21T15:33:34Z

sound/soc/intel/common/soc-acpi-intel-get-tplg.c

+			dev_dbg(card->dev,
+				"dai_link %s is not supported by sperated tplg yet\n",
+				dai_link->name);
+			return 0;


should we return here or continue?

We should return 0 so that snd_sof_load_topology() will use the monolithic topology.

ranj063 · 2025-02-21T15:47:21Z

sound/soc/sof/topology.c

+		ret = firmware_request_nowarn(&fw, tplg_files[i], scomp->dev);
+		if (ret < 0) {
+			if (i == 0 && file_cnt) {
+				dev_dbg(scomp->dev, "Fail back to %s\n", file);


@bardliao you're assuming here that the monolithic topology file always exists which is true for the current platforms. But once we move to the split sub-topologies, we may not even have the monolithic topologies for future platforms right?

No, I didn't assume that the monolithic topology file always exists. I tested the return value of request_firmware(&fw, file, scomp->dev); and return error if request_firmware() failed. That is the same as current code.

if you didnt assume there's a monolithic topology, what did you mean by fall back? and there's a typo in fallback

It means we tried the sub-topologies but failed. Now we are trying the monolithic topology. But we will know if the monolithic topology exists after calling request_firmware()

ranj063 · 2025-02-21T16:30:59Z

sound/soc/intel/common/soc-acpi-intel-get-tplg.c

+		/*
+		 * The tplg file naming rule is sof-<platform>-<function>-id<BE id number>.tplg
+		 * where <platform> is only required for the DMIC function as the nhlt blob
+		 * is platform depentent.


typo dependent

ranj063 · 2025-02-24T04:11:14Z

sound/soc/sof/topology.c

+		tplg_cnt = sof_pdata->machine->get_tplg_files(scomp->card, sof_pdata->machine,
+							      sof_pdata->tplg_filename_prefix,
+							      &tplg_files);
+		if (tplg_cnt < 0)


you need to free tplg_files in the error path

ranj063 · 2025-02-24T04:21:32Z

sound/soc/sof/topology.c

+				}
+			} else {
+				if (i > 0)
+					snd_soc_tplg_component_remove(scomp);


actually after thinking about it, I think you dont need to do this at all. All of the aub-topologies are associated with the same component, so if a failure happens during loading for any of the sub-topologies, the component remove will handle all of the previously successfully loaded objects automatically. Maybe you can just add that comment here for clarity

A topology can be split into several sub-topologies. The sub-topologies can be used across cards. In other words, we can create multiple mini topologies and let driver select what it needs. However, the topology depends on the cards. Add a get_tplg_files ops allow cards have their own sub-topology file names. The commit add an empty ops first. Will add the first ops in the follow up commit. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>

Add sof_sdw_get_tplg_files ops to get sub-topology file names for the sod_sdw card. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>

With the get_tplg_files ops, sub-topologies could be used and the defaule topology is not necessary in the file system. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>

The audio configs with multi-function SDCA codecs can use the sof_sdw_get_tplg_files ops to get sub-topologies dynamically. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>

bardliao requested a review from ujfalusi October 18, 2024 13:32

bardliao force-pushed the test-multi-topologies branch from 7eb5975 to ffadfbb Compare October 21, 2024 08:38

bardliao force-pushed the test-multi-topologies branch from ffadfbb to 1deb725 Compare October 28, 2024 10:47

bardliao force-pushed the test-multi-topologies branch from 1deb725 to 3264fc3 Compare November 13, 2024 05:44

ujfalusi reviewed Nov 14, 2024

View reviewed changes

bardliao force-pushed the test-multi-topologies branch 2 times, most recently from 6259f1d to 78eed41 Compare November 20, 2024 06:55

bardliao force-pushed the test-multi-topologies branch 2 times, most recently from 95da27b to 9641e65 Compare November 22, 2024 08:14

bardliao changed the title ~~TEST: load topology for each device~~ load topology for each device Nov 27, 2024

bardliao marked this pull request as ready for review November 27, 2024 01:50

bardliao requested a review from ranj063 as a code owner November 27, 2024 01:50

bardliao force-pushed the test-multi-topologies branch from 9641e65 to 788e9bf Compare November 27, 2024 02:09

ujfalusi reviewed Dec 13, 2024

View reviewed changes

bardliao mentioned this pull request Dec 13, 2024

Topology2: add topologies for SDCA functions thesofproject/sof#9668

Open

bardliao force-pushed the test-multi-topologies branch 2 times, most recently from f5eb366 to ec01782 Compare December 16, 2024 02:51

bardliao force-pushed the test-multi-topologies branch 2 times, most recently from f86b410 to 5a6f019 Compare January 16, 2025 09:02

bardliao requested a review from lgirdwood January 16, 2025 09:16

bardliao force-pushed the test-multi-topologies branch from 5a6f019 to ee0ee64 Compare January 17, 2025 01:55

bardliao force-pushed the test-multi-topologies branch from ee0ee64 to c2253fe Compare February 7, 2025 08:32

bardliao requested review from plbossart, kv2019i and dbaluta as code owners February 7, 2025 08:32

bardliao force-pushed the test-multi-topologies branch from c2253fe to 779861b Compare February 7, 2025 08:33

ujfalusi reviewed Feb 7, 2025

View reviewed changes

lyakh previously approved these changes Feb 14, 2025

View reviewed changes

bardliao dismissed lyakh’s stale review via 5e1ab39 February 14, 2025 14:23

bardliao force-pushed the test-multi-topologies branch from 951be49 to 5e1ab39 Compare February 14, 2025 14:23

lgirdwood reviewed Feb 17, 2025

View reviewed changes

sound/soc/sof/card-tplg-ops.c Outdated Show resolved Hide resolved

sound/soc/sof/card-tplg-ops.c Outdated Show resolved Hide resolved

sound/soc/sof/card-tplg-ops.c Outdated Show resolved Hide resolved

bardliao force-pushed the test-multi-topologies branch from 5e1ab39 to 448deb3 Compare February 18, 2025 05:34

lgirdwood previously approved these changes Feb 18, 2025

View reviewed changes

ranj063 reviewed Feb 18, 2025

View reviewed changes

bardliao dismissed lgirdwood’s stale review via 7863612 February 19, 2025 09:12

bardliao force-pushed the test-multi-topologies branch from 448deb3 to 7863612 Compare February 19, 2025 09:12

ujfalusi reviewed Feb 21, 2025

View reviewed changes

bardliao force-pushed the test-multi-topologies branch from 7863612 to 06dfb66 Compare February 21, 2025 14:49

ranj063 reviewed Feb 21, 2025

View reviewed changes

bardliao force-pushed the test-multi-topologies branch from 06dfb66 to 61fd30e Compare February 24, 2025 03:29

ranj063 reviewed Feb 24, 2025

View reviewed changes

bardliao force-pushed the test-multi-topologies branch from 61fd30e to f0c60a5 Compare February 24, 2025 05:52

bardliao added 7 commits February 24, 2025 13:59

ASoC: Intel: add sof_sdw_get_tplg_files ops

2644bbe

Add sof_sdw_get_tplg_files ops to get sub-topology file names for the sod_sdw card. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>

ASoC: SOF: don't check tplg file if get_tplg_files ops is set

fdd86ae

With the get_tplg_files ops, sub-topologies could be used and the defaule topology is not necessary in the file system. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>

ASoC: Intel: soc-acpi-intel-lnl-match: set get_tplg_files ops

5fe8bd5

The audio configs with multi-function SDCA codecs can use the sof_sdw_get_tplg_files ops to get sub-topologies dynamically. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>

ASoC: Intel: soc-acpi-intel-arl-match: set get_tplg_files ops

b684211

The audio configs with multi-function SDCA codecs can use the sof_sdw_get_tplg_files ops to get sub-topologies dynamically. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>

ASoC: Intel: soc-acpi-intel-ptl-match: add get_tplg_files ops

60451b1

The audio configs with multi-function SDCA codecs can use the sof_sdw_get_tplg_files ops to get sub-topologies dynamically. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>

ASoC: Intel: soc-acpi-intel-mtl-match: add get_tplg_files ops

cfb0e72

The audio configs with multi-function SDCA codecs can use the sof_sdw_get_tplg_files ops to get sub-topologies dynamically. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>

bardliao force-pushed the test-multi-topologies branch from f0c60a5 to cfb0e72 Compare February 24, 2025 06:02

		@@ -0,0 +1,120 @@
		// SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause)


		#define SOF_INTEL_PLATFORM_NAME_MAX 4

		int get_sof_sdw_tplg_files(struct snd_soc_component scomp, const char file,

load topology for each device #5209

Are you sure you want to change the base?

load topology for each device #5209

Conversation

bardliao commented Oct 18, 2024

bardliao commented Oct 21, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bardliao commented Nov 20, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bardliao commented Jan 16, 2025

ujfalusi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ranj063 Feb 10, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ranj063 Feb 10, 2025 •

edited

Loading