Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ujfalusi wants to merge 1 commit into from
Closed

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

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 33 additions & 2 deletions getting_started/intel_debug/introduction.rst
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -178,11 +178,42 @@ reconfigured with tools but requires expert knowledge of the ALSA/ASoC/topology
- CONFIG = topology variant needed for detected hardware configuration
* - Tiger Lake and newer
- IPC4
- /lib/firmware/intel/sof-ipc4-tplg/sof-CONFIG.tplg
- /lib/firmware/intel/sof-ipc4-tplg/PLAT/sof-CONFIG.tplg
- CONFIG = topology variant needed for detected hardware configuration

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``

@deb-inteldeb-intelJan 3, 2024

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- 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``


::

.
└── intel
├── sof-ace-tplg -> sof-ipc4-tplg/ACE1
└── sof-ipc4-tplg
├── ACE1
│ ├── sof-*.tplg
│ ├── ...
│ └── sof-*.tplg
├── ACE2 -> ACE1
├── adl -> CAVS2.5
├── adl-n -> CAVS2.5
├── adl-s -> CAVS2.5
├── arl -> ACE1
├── arl-s -> ACE1
├── CAVS2.5
│ ├── sof-*.tplg
│ ├── ...
│ └── sof-*.tplg
├── ehl -> CAVS2.5
├── lnl -> ACE2
├── mtl -> ACE1
├── rpl -> CAVS2.5
├── rpl-s -> CAVS2.5
├── tgl -> CAVS2.5
└── tgl-h -> CAVS2.5

@plbossartplbossartJan 9, 2024

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@ujfalusiujfalusiJan 10, 2024•
edited
Loading

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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-tplg

The 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:

DirectoryContent
sofIPC3 firmware files
sof-tplgIPC3 topology files
sof-ipc4IPC4 firmware files (ACE1/ACE2/CAVS2.5/some_arch/some_other_arch)
sof-ace-tplgIPC4 topology files (ACE1/ACE2)
sof-ipc4-tplgIPC4 topology files (for CAV2.5 platforms)
sof-some_arch-tplgIPC4 topology files (for some_arch only)
sof-some_other_arch-tplgIPC4 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?

DirectoryContent
sofIPC3 firmware files
sof-tplgIPC3 topology files
sof-ipc4IPC4 firmware files (ACE1/ACE2/CAVS2.5/some_arch/some_other_arch)
sof-ipc4-tplgIPC4 topology files (ACE1/ACE2/CAVS2.5/some_arch/some_other_arch)
sof-ace-tplgsymlink to sof-ipc4-tplg for backwards compatibility (to be kept for few years)

@plbossartplbossartJan 10, 2024

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"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.

@ujfalusiujfalusiJan 10, 2024

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"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.

@plbossartplbossartJan 10, 2024•
edited
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Important notices:
- For compatibility reasons for **Meteor Lake and newer** ``/lib/firmware/intel/sof-ace-tplg`` must be symlinked to ``/lib/firmware/intel/sof-ipc4-tplg``
- The standard Linux firmware search path and order is followed. The above table covers the base "/lib/firmware" case. See https://docs.kernel.org/driver-api/firmware/fw_search_path.html for more information.
- The topology folder and filename can be overridden with "tplg_path" and "tplg_filename" `snd_sof_pci` kernel parameters.

Expand Down