intel_debug: introduction: Update default IPC4 topology path with exa… #482
Conversation
ujfalusi
requested review from
deb-intel,
intelkevinputnam,
lgirdwood,
mmaka1 and
mwasko
as code owners
…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
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
|
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. |
or
tgl-h symlinked to the same CAVS2.5 directory, please see the patch with the example. |
|
my brain is already hurting. We have different types of platforms... Which ones do we want to track? |
We must separate the architectures (cAVS/ACE). As I said we could have just architecture folders and no platform: But that would make the generic path generation in core impossible or awkward since on top of the |
|
Option C added to thesofproject/sof#8683 (comment) |
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. 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. |
|
|
||
| Practical notes on IPC4 deployment | ||
| - In practice the topology files should be grouped by generations and platforms should be symlinked to the matching generation | ||
| - For compatibility reasons for **Meteor Lake**'s ``/lib/firmware/intel/sof-ace-tplg`` must be symlinked to ``/lib/firmware/intel/sof-ipc4-tplg/ACE1`` |
There was a problem hiding this comment.
| - For compatibility reasons for **Meteor Lake**'s ``/lib/firmware/intel/sof-ace-tplg`` must be symlinked to ``/lib/firmware/intel/sof-ipc4-tplg/ACE1`` | |
| - For compatibility reasons with respect to **Meteor Lake**, ``/lib/firmware/intel/sof-ace-tplg`` must be symlinked to ``/lib/firmware/intel/sof-ipc4-tplg/ACE1`` |
|
Moving to draft to avoid ninja-merging it. |
| ├── rpl-s -> CAVS2.5 | ||
| ├── tgl -> CAVS2.5 | ||
| └── tgl-h -> CAVS2.5 | ||
|
|
There was a problem hiding this comment.
Sorry @ujfalusi, this list looks too exhaustive and to some extent more confusing than the initial naming.
Apart from naming conventions that can be argued on forever, what is wrong with the existing layout and can we not keep sof-ace-tplg for MTL/LNL, and change the layout as needed for future platforms?
Is there really anything broken with the current layout for MTL/LNL?
There was a problem hiding this comment.
Sorry @ujfalusi, this list looks too exhaustive and to some extent more confusing than the initial naming.
I have put this to draft as imho thesofproject/sof#8712 would scale correctly without complexity.
Apart from naming conventions that can be argued on forever, what is wrong with the existing layout
Right, so how does things looks today with linux-firmware and sof-firmware installed?
# cd /lib/firmware/intel/
/lib/firmware/intel# ls -l | grep -E 'avs|sof'
drwxr-xr-x 5 root root 4096 20.11. 03:52 avs
lrwxrwxrwx 1 root root 26 11.12. 18:21 dsp_fw_bxtn.bin.zst -> avs/apl/dsp_basefw.bin.zst
lrwxrwxrwx 1 root root 26 11.12. 18:21 dsp_fw_cnl.bin.zst -> avs/cnl/dsp_basefw.bin.zst
lrwxrwxrwx 1 root root 26 11.12. 18:21 dsp_fw_glk.bin.zst -> avs/apl/dsp_basefw.bin.zst
lrwxrwxrwx 1 root root 26 11.12. 18:21 dsp_fw_kbl.bin.zst -> avs/skl/dsp_basefw.bin.zst
lrwxrwxrwx 1 root root 26 11.12. 18:21 dsp_fw_release.bin.zst -> avs/skl/dsp_basefw.bin.zst
drwxr-xr-x 4 root root 4096 2. 1. 14:23 sof
drwxr-xr-x 2 root root 4096 2. 1. 14:23 sof-ace-tplg
drwxr-xr-x 3 root root 4096 21.11. 17:37 sof-ipc4
drwxr-xr-x 2 root root 20480 2. 1. 14:23 sof-tplgThe IPC3 firmware files are under sof and the corresponding topology files are under sof-tplg
The IPC4 firmware files are under sof-ipc4 and the corresponding topology files are under sof-ace-tplg
and can we not keep sof-ace-tplg for MTL/LNL, and change the layout as needed for future platforms?
Yes, we can think after a new IPC4 architecture is released to public on where it is going to end up, my aim with thesofproject/sof#8712 is to avoid that completely.
Bu let's say we release CAV2.5 files, the kernel now follows the sof-docs specification so CAVS2.5 will expect firmware files under sof-ipc4 and the corresponding topology files under sof-ipc4-tplg. Then we release other platforms for a new architecture, likely colliding with existing "generic" topology files (sof-hda-generic-2/4ch), so:
| Directory | Content |
|---|---|
| sof | IPC3 firmware files |
| sof-tplg | IPC3 topology files |
| sof-ipc4 | IPC4 firmware files (ACE1/ACE2/CAVS2.5/some_arch/some_other_arch) |
| sof-ace-tplg | IPC4 topology files (ACE1/ACE2) |
| sof-ipc4-tplg | IPC4 topology files (for CAV2.5 platforms) |
| sof-some_arch-tplg | IPC4 topology files (for some_arch only) |
| sof-some_other_arch-tplg | IPC4 topology files (for some_other_arch only) |
Is there really anything broken with the current layout for MTL/LNL?
Apart from not scalable and going to be a confusing mess over time, no, nothing.
But let's say we will transition to a new and better IPC version, let's say IPC5 and we are fortunate that ACE can be supported by it. Then what? How sof-ace-tplg is not for IPC5 but only IPC4?
The new IPC version is hypothetical, just for highlighting the non scalability of what we have.
What is wrong with my proposal?
| Directory | Content |
|---|---|
| sof | IPC3 firmware files |
| sof-tplg | IPC3 topology files |
| sof-ipc4 | IPC4 firmware files (ACE1/ACE2/CAVS2.5/some_arch/some_other_arch) |
| sof-ipc4-tplg | IPC4 topology files (ACE1/ACE2/CAVS2.5/some_arch/some_other_arch) |
| sof-ace-tplg | symlink to sof-ipc4-tplg for backwards compatibility (to be kept for few years) |
There was a problem hiding this comment.
"sof-ace-tplg symlink to sof-ipc4-tplg for backwards compatibility (to be kept for few years)"
To be clear, we have NO PLANS to change the IPC4 default path in the kernel files, do we? That would mean that the sof-ace-tplg path will have to be maintained forever
We also have NO PLANS to change the IPC type for MTL/LNL, so I am not sure that the scalability issue is a problem we need to solve.
What we do know is that we have to avoid a conflict for the next generations, but that doesn't mean we need to align and risk breaking existing stuff with late changes.
There was a problem hiding this comment.
"sof-ace-tplg symlink to sof-ipc4-tplg for backwards compatibility (to be kept for few years)"
To be clear, we have NO PLANS to change the IPC4 default path in the kernel files, do we? That would mean that the sof-ace-tplg path will have to be maintained forever
I would change the path in kernel after the second sof-bin release with the sof-ipc4-tplg + sof-ace-tplg symlink.
Distros update the sof-firmware and in case of issue we always ask for updated sof-bin.
We also have NO PLANS to change the IPC type for MTL/LNL, so I am not sure that the scalability issue is a problem we need to solve.
That was hypothetical note.
What we do know is that we have to avoid a conflict for the next generations, but that doesn't mean we need to align and risk breaking existing stuff with late changes.
We can have a consistent location with minimal effort today, tomorrow it is not going to be possible and we will have an inconsistent mess to manage for eternity.
There was a problem hiding this comment.
why do you need to change the path in kernel? That's asking for trouble with multiple versions of the kernel pointing to different locations.
Also why would we need to track all versions of SOC at the topology level? We should only do so if there's a good reason where the compatibility with previous solution needs to be broken.
My counter proposal would be
sof-ipc4-tplg/
all existing cavs stuff without any further redirections
ace/ all topologies for MTL and LNL (i.e this covers ace1.x and ace2.x)
aceN/ topologies for the first 'N' version that is no longer compatible with the 'ace' topologies
sof-ace-tplg/ symlink for sof-ipc4-tplg/ace
We have a similar handling for the PCI devices, we group them in the same files until we can't because they require different handling. No need to track each SOC separately if we can avoid doing so.
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 thesofproject/linux#3867) and CI may have some hardcoded tables but no logic. EDIT: these rules are "somewhat" duplicated in the |
|
Closing, replaced by a simple text update: #483 |
5 participants
…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