Hi Paul, It's not surprising that there would be some unconditional HDaudio DMA dependencies, it's what is used for development and it's natural that shortcuts would be taken in the absence of feedback that it breaks other platforms.

There is internal Intel documentation which hopefully will find its way upstream at some point. A good topic for the next TSC?

Regards, -Pierre

On 3/20/23 09:28, Paul Olaru wrote:

It does help a bit. I am trying to do the actual port and have done the bare minimum for the kernel to attempt to load the firmware as an IPC4 one.

Now what pretty much stumps me (I have tried to start an effort to port i.MX to IPC4) is the firmware side. By now I have found a good amount of assumptions, including some places where HDA and ALH defines are used unconditionally (I have put some dummy values for now) and what I need to figure out now is the base_fw component, which seems to be a bit of a mystery.

Is there any guide, tutorial or reference I can use to make it easier to port i.MX to IPC4? Do I just take the example from Tigerlake and see how it can be adjusted, or what else do I do? ________________________________ De la: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Trimis: luni, 20 martie 2023 16:25 Către: Daniel Baluta daniel.baluta@nxp.com; Liam Girdwood liam.r.girdwood@intel.com Cc: sound-open-firmware@alsa-project.org sound-open-firmware@alsa-project.org; Paul Olaru paul.olaru@nxp.com; Iuliana Prodan iuliana.prodan@nxp.com Subiect: [EXT] Re: How does SOF selects between IPC3 and IPC4?

Caution: EXT Email

Hi Daniel,

...

How does SOF selects between IPC3 and IPC4? Is it at runtime? Module parameter?

We are looking on enabling IPC4 while also keeping IPC3 support in place.

It's by default at build-time, but we also have an 'ipc_type' module parameter that can override platform defaults set in stone at build time, and look for different paths/names for topology, e.g.

static const struct sof_dev_desc tgl_desc = { .ipc_supported_mask = BIT(SOF_IPC) | BIT(SOF_INTEL_IPC4), .ipc_default = SOF_IPC, .default_fw_path = { [SOF_IPC] = "intel/sof", [SOF_INTEL_IPC4] = "intel/avs/tgl", }, .default_lib_path = { [SOF_INTEL_IPC4] = "intel/avs-lib/tgl", }, .default_tplg_path = { [SOF_IPC] = "intel/sof-tplg", [SOF_INTEL_IPC4] = "intel/avs-tplg", }, .default_fw_filename = { [SOF_IPC] = "sof-tgl.ri", [SOF_INTEL_IPC4] = "dsp_basefw.bin", },

static const struct sof_dev_desc mtl_desc = { .ipc_supported_mask = BIT(SOF_INTEL_IPC4), .ipc_default = SOF_INTEL_IPC4, .default_fw_path = { [SOF_INTEL_IPC4] = "intel/sof-ipc4/mtl", }, .default_tplg_path = { [SOF_INTEL_IPC4] = "intel/sof-ace-tplg", },

TigerLake supports IPC3 by default and IPC4 optionally for development. MeteorLake is IPC4 only.

In addition, we have different descriptors for IPC callbacks.

Does this help?

Regards, -Pierre