intel_debug: introduction: Update default IPC4 topology path with exa…

[ujfalusi]

…mple

We need to keep the topology files for different ADSP generations separate because they can include NHLT blobs and the blobs are not compatible among different versions.

While this only affects generically named topology files (sof-hda-generic*.tplg), it is cleaner to expect the topology files to be stored under different directories rather than having some in sof-ipc4-tplg root and some under directories. Keeping the generational topology files in separate directory also enables us to offer backwards compatibility for deployed MTL installs with older kernels.

The new default topology path shall be: /lib/firmware/intel/sof-ipc4-tplg/PLAT/sof-CONFIG.tplg

With a practical note that the PLAT is symlinked to a common directory for the generation they belopng to: . └── intel ├── sof-ace-tplg -> sof-ipc4-tplg/ACE1 └── sof-ipc4-tplg ├── ACE1 ├── CAVS2.5 ├── mtl -> ACE1 ├── tgl -> CAVS2.5 └── tgl-h -> CAVS2.5

[plbossart]

How would LunarLake be handled? With an ACE2.0 directory? If yes, we are going to have multiple files that are really the same under different directories?

Also why would we expose tgl-h at the topology level? This is too detailed IMHO.

[ujfalusi]

How would LunarLake be handled? With an ACE2.0 directory? If yes, we are going to have multiple files that are really the same under different directories? ACE2 is symlinked to ACE1 unless we need a separate directory for some reason, optionally we can just symlink lnl to ACE1

ACE2 -> ACE1
lnl -> ACE2

or

lnl -> ACE1

Also why would we expose tgl-h at the topology level? This is too detailed IMHO.

tgl-h symlinked to the same CAVS2.5 directory, please see the patch with the example. The reason why I have proposed this is that in this way the default topology path can be generated in core based on vendor/platform name alone (a reworked/updated https://github.com/thesofproject/linux/pull/4603). If we don't want to have different path profiles per IPC versions then we could just use sof-ipc4-tplg/cavs2.5, sof-ipc4-tplg/ace1 and sof-ipc4-tplg/ace2 (ace2 -> ace1) and no platform symlinks, but we need to constantly update the platform names for each generations in sof-docs also to avoid going out of sync with reality.

[plbossart]

my brain is already hurting. We have different types of platforms... a) different architecture (cAVS/ACE) b) different DSP skus with more/fewer cores and hence potential topology differences c) different IO IP versions (e.g. DMIC for MTL+ different from MTL-) d) artificial differences due to signature requirements.

Which ones do we want to track?

[ujfalusi]

my brain is already hurting. We have different types of platforms... a) different architecture (cAVS/ACE) b) different DSP skus with more/fewer cores and hence potential topology differences c) different IO IP versions (e.g. DMIC for MTL+ different from MTL-) d) artificial differences due to signature requirements.

Which ones do we want to track?

We must separate the architectures (cAVS/ACE). This is linux firmware location, so I'm using the same platform definitions we have for platforms within architectures, like we do with the firmware files.

As I said we could have just architecture folders and no platform:

.
└── intel
    ├── sof-ace-tplg -> sof-ipc4-tplg/ace1
    └── sof-ipc4-tplg
        ├── ace1
        │   ├── sof-hda-generic-2ch.tplg
        │   ├── sof-hda-generic-4ch.tplg
        │   ├── sof-hda-generic-idisp.tplg
        │   ├── sof-hda-generic.tplg
        │   ├── sof-lnl-rt711-4ch.tplg
        │   ├── sof-lnl-rt711-l0-rt1316-l23-rt714-l1.tplg
        │   ├── sof-mtl-cs42l43-l0-cs35l56-l12.tplg
        │   ├── sof-mtl-es83x6-ssp1-hdmi-ssp02.tplg
        │   ├── sof-mtl-max98357a-rt5682-ssp2-ssp0-2ch-pdm1.tplg
        │   ├── sof-mtl-max98357a-rt5682-ssp2-ssp0.tplg
        │   ├── sof-mtl-max98357a-rt5682.tplg
        │   ├── sof-mtl-rt1019-rt5682.tplg
        │   ├── sof-mtl-rt1318-l12-rt714-l0.tplg
        │   ├── sof-mtl-rt5650-dts.tplg
        │   ├── sof-mtl-rt711-4ch.tplg
        │   ├── sof-mtl-rt711-l0-rt1316-l23-rt714-l1.tplg
        │   ├── sof-mtl-rt712-l0-rt1712-l3.tplg
        │   ├── sof-mtl-rt713-l0-rt1316-l12-rt1713-l3.tplg
        │   ├── sof-mtl-rt713-l0-rt1316-l12.tplg
        │   ├── sof-mtl-rt722-l0.tplg
        │   └── sof-mtl-sdw-cs42l42-l0-max98363-l2.tplg
        ├── ace2 -> ace1
        └── cavs2.5
            ├── sof-adl-rt711-4ch.tplg
            ├── sof-adl-rt711-l0-rt1316-l12-rt714-l3.tplg
            ├── sof-hda-generic-2ch.tplg
            ├── sof-hda-generic-4ch.tplg
            ├── sof-hda-generic-idisp.tplg
            ├── sof-hda-generic.tplg
            ├── sof-tgl-cs42l43-l3-cs35l56-l01.tplg
            ├── sof-tgl-rt711-rt1308-4ch.tplg
            ├── sof-tgl-rt711-rt1308-rt715.tplg
            ├── sof-tgl-rt711-rt1316-rt714.tplg
            ├── sof-tgl-rt712.tplg
            └── sof-tgl-rt715-rt711-rt1308-mono.tplg

But that would make the generic path generation in core impossible or awkward since on top of the vendor and platform strings we would need architecture/generation string to be able to guess which platform belongs to which architecture.

[kv2019i]

Option C added to https://github.com/thesofproject/sof/issues/8683#issuecomment-1875398182

[ujfalusi]

my brain is already hurting. We have different types of platforms...

The reason that I have opted with the definition I have in this PR is to avoid my brain hurting and to not try to introduce complex rules, conditions, parameters on where to look for a topology file. In essence we need this for the sof-hda-generic-2/4ch.tplg, right? But what if we will have something else? If we only special case this two topology files than it is going to be a pain to document and get it right, especially that we need to have sof-ace-tplg compatibility with older kernels...

We will maximum duplicate one file in this way (sof-hda-generic.tplg), in theory we could survive with a single one for all platforms. In theory.

[ujfalusi]

Moving to draft to avoid ninja-merging it. We might not need to do an update at all if the solution I'm working on is accepted.

[marc-hb]

The reason that I have opted with the definition I have in this PR is to avoid my brain hurting and to not try to introduce complex rules, conditions, parameters on where to look for a topology file.

Complexity is never good but this affects only the Linux kernel, correct? I don't think these rules are duplicated anywhere else. sof-test is still grepping the kernel logs (until https://github.com/thesofproject/linux/issues/3867) and CI may have some hardcoded tables but no logic.

EDIT: these rules are "somewhat" duplicated in the sof/tools/topology/ tree structure of course.

[ujfalusi]

Closing, replaced by a simple text update: #483