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.

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.

The existing code point tuples[*num_copied_tuples].value.s to elem->string which works fine if there is only one topology is handled and all the tuples are handled before the topology fw is released. However, we will handle multiple topologies and the tuples may be used after the topology fw is release. Ues devm_kasprintf to allocate the string for the tuples to avoid invalid access. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>

ujfalusi · 2024-12-13T11:04:03Z

sound/soc/sof/topology.c

@@ -2489,7 +2489,6 @@ int snd_sof_load_topology(struct snd_soc_component *scomp, const char *file)
 	if (ret < 0) {
 		dev_err(scomp->dev, "error: tplg component load failed %d\n",
 			ret);
-		ret = -EINVAL;
 	}


you can also drop the curly brackets

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.

No need to convert the return value of snd_soc_tplg_component_load(). Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>

Get device information from dai links and load topology for each device. This allow user create a topology for single device. The driver will select the needed topologies and we don't need to create topologies for each product. 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 from 78eed41 to 95da27b Compare November 20, 2024 12:09

bardliao force-pushed the test-multi-topologies branch 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

ASoC: SOF: topology: don't convert error code

7c8cf93

No need to convert the return value of snd_soc_tplg_component_load(). Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>

bardliao mentioned this pull request Dec 13, 2024

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

Draft

bardliao force-pushed the test-multi-topologies branch from 788e9bf to f5eb366 Compare December 13, 2024 13:42

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

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

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

Choose a reason for hiding this comment