ASoC: SOF: Firmware (file) layout profile support (including the generic IPC type naming)

[ujfalusi]

Hi,

This PR contains #4301 as the first 10 patch, the new content is starting at
ASoC: SOF: pci-cnl: Correct the firmware filename for cfl and cml

Currently we have a set of string arrays to define the default paths and firmware filename for a platform (in struct sof_dev_desc) per IPC type - so we can have one set of strings for a given IPC type.
The fact that these strings are defined in the kernel, it is posing restriction on the file placement in filesystem level and prevent backwards, forwards compatibility in case a new layout is required or decided.
IPC3 has a standardized and stable filesystem layout among all vendors and platforms:

firmware path:		<vendor>/sof</fw_path_postfix>
firmware name:		sof-<platform>.ri
topology path:		<vendor>/sof-tplg/

note: fw_path_postfix: used by Intel for community key signed binaries.

IPC4 at the moment have two Intel layouts and no generic vendor neutral one. Moving these to a generic one would require interlocked update of firmware and kernel, which is realistically not a possibility in most cases.

This set proposes a solution which will allow multiple filesystem layout per IPC type, all generated and defined in core for a standardized presentation.
Device descriptions will include only a vendor name and platform name, for example:

diff --git a/sound/soc/sof/amd/pci-rmb.c b/sound/soc/sof/amd/pci-rmb.c
index 5cae889f9b35..a64e135b0420 100644
--- a/sound/soc/sof/amd/pci-rmb.c
+++ b/sound/soc/sof/amd/pci-rmb.c
@@ -47,15 +47,8 @@ static const struct sof_dev_desc rembrandt_desc = {
 	.chip_info		= &rembrandt_chip_info,
 	.ipc_supported_mask     = BIT(SOF_IPC_TYPE_3),
 	.ipc_default            = SOF_IPC_TYPE_3,
-	.default_fw_path	= {
-		[SOF_IPC_TYPE_3] = "amd/sof",
-	},
-	.default_tplg_path	= {
-		[SOF_IPC_TYPE_3] = "amd/sof-tplg",
-	},
-	.default_fw_filename	= {
-		[SOF_IPC_TYPE_3] = "sof-rmb.ri",
-	},
+	.vendor			= "amd",
+	.platform		= "rmb",
 	.nocodec_tplg_filename	= "sof-acp.tplg",
 	.ops			= &sof_rembrandt_ops,
 	.ops_init		= sof_rembrandt_ops_init,

or

diff --git a/sound/soc/sof/intel/pci-tgl.c b/sound/soc/sof/intel/pci-tgl.c
index 613119ec37a2..d9c2d6868ed6 100644
--- a/sound/soc/sof/intel/pci-tgl.c
+++ b/sound/soc/sof/intel/pci-tgl.c
@@ -19,6 +19,8 @@
 /* platform specific devices */
 #include "hda.h"
 
+static const char vendor_string[] = "intel";
+
 static const struct sof_dev_desc tgl_desc = {
 	.machines               = snd_soc_acpi_intel_tgl_machines,
 	.alt_machines		= snd_soc_acpi_intel_tgl_sdw_machines,
@@ -31,21 +33,8 @@ static const struct sof_dev_desc tgl_desc = {
 	.ipc_supported_mask	= BIT(SOF_IPC_TYPE_3) | BIT(SOF_IPC_TYPE_4),
 	.ipc_default		= SOF_IPC_TYPE_3,
 	.dspless_mode_supported	= true,		/* Only supported for HDaudio */
-	.default_fw_path = {
-		[SOF_IPC_TYPE_3] = "intel/sof",
-		[SOF_IPC_TYPE_4] = "intel/avs/tgl",
-	},
-	.default_lib_path = {
-		[SOF_IPC_TYPE_4] = "intel/avs-lib/tgl",
-	},
-	.default_tplg_path = {
-		[SOF_IPC_TYPE_3] = "intel/sof-tplg",
-		[SOF_IPC_TYPE_4] = "intel/avs-tplg",
-	},
-	.default_fw_filename = {
-		[SOF_IPC_TYPE_3] = "sof-tgl.ri",
-		[SOF_IPC_TYPE_4] = "dsp_basefw.bin",
-	},
+	.vendor			= vendor_string,
+	.platform		= "tgl",
 	.nocodec_tplg_filename = "sof-tgl-nocodec.tplg",
 	.ops = &sof_tgl_ops,
 	.ops_init = sof_tgl_ops_init,

The strings are going to be created by the core.

With this change the kernel can support multiple filesystem layout per IPC type and can discover the one which is deployed on the system.
We can also fall back to other IPC type in case the requested one not found on the filesystem (we can only check for the firmware image at this point).

[ujfalusi]

Looks like CML_HEL_RT5682 cannot find the firmware, other CML devices can , but this one is using community key. strange

[ujfalusi]

On the CI machine:

ls -al /lib/firmware/intel/sof/community/ | grep sof-cml.ri
lrwxrwxrwx 1 root root   34 Apr 18 10:03 sof-cml.ri -> /lib/firmware/intel/sof/sof-cnl.ri

on a arch machine:

ls -al /lib/firmware/intel/sof-v2.2.4/community | grep sof-cml.ri
lrwxrwxrwx 1 root root     10  7. 1. 23:17 sof-cml.ri -> sof-cnl.ri

so CI is using custom layout for this machine.

[ujfalusi]

I can fix this by forcing similar symlinking for IPC4, so link cml and cfl directories to cnl to make CI happy and probably other custom deployments out there?

Is this acceptable solution?

[ujfalusi]

Changes since v1:

• align the IPC4 path names with existing IPC3 standard for CFL, CML in pci-cnl.c

[plbossart]

IPC4 at the moment have two Intel layouts and no generic vendor neutral one.

Why is this a problem?

a) the first Intel layout was defined by our colleagues with the 'firmware tester'. it is what it is.
b) the second layout was defined by popular vote in our own team. It is what it is. If we want to change it, we need a popular voice again.
c) we have no plan to enforce any naming or restrictions on other vendors. The naming is the problem at each vendor level, depending on if and how they plan to release binaries.

Can we please go back to the problem statement?

1. what are we trying to achieve?
2. what is broken?
3. what does the suggested solution bring?
4. how does this help the community and other vendors?

Edit
5) how does this leave our partners using Intel platform the freedom to use their own layout based on overlays? There will be multiple firmwares/libraries generated for the same SoC, so we can't have a one-size-fits-all layout. That was the basis for the 'default_path' than can be overridden at will. It was not planned to be a generic solution, only one that would be followed by Intel only for sof-bin releases. When sof-bin is not used, there is no convention required.

[kv2019i]

Sounds like @plbossart 's comments need to be addressed first. If we drop the idea of generic lookup path, I guess a minimal version of fw-file-layout.c that would just try the different IPC fw+tplg entries in order (if they are defined), would still be possible. E.g. for platforms where both IPC3 and IPC4 entries are defined, kernel would try to use IPC4 first, check fw+tplg and if available, use those, and if not, fallback to IPC3.

[kv2019i]

I wonder if the PR could be kept smaller by accepting that SOF_IPC continues to be used to refer to 3.

[ujfalusi]

I think it is more intuitive for the first look to have SOF_IPC_TYPE_3 than SOF_IPC
IPC4 is SOF_IPC, it is IPC type used by SOF.

[kv2019i]

So this is the magic bit that allows to choose IPC major version based on available installed FW.

UPDATE: i.e. this would allow us to add SOF2.6 binaries to sof-bin release for distributions, and when this kernel hits a system with SOF2.6 installed, a portion of systems would move to use IPC4 and the new SOF2.6 release while older platforms would continue to use stable SOF2.2 binaries.

[ujfalusi]

Yes, we could change the default IPC type to IPC4 for everything in pci-tgl.c and provide only selected platform's IPC4 firmware (where we have good coverage of topologies). That would work fine.
This would also allow the possibility (if ever needed) to change the location of the SOF firmware things to
/lib/firmware/sof/< vendor >/< ipc_type >/.../
if the profile is described in kernel.

But looks like this is an overshot, so I'll try to scale it back.

[ujfalusi]

Closing, completely new approach will be pushed