ASoC: SOF: Initial support for IPC4 compress offload #5647

ujfalusi · 2026-01-14T12:00:10Z

Hi,

inital (draft) support for compress offload with IPC4 on Intel platforms (MTL+).

There are still missing features, and few areas to improve, tune, but it works reasonably well and the hope is that the IPC3 compr is still functional.

@dbaluta, if you could be able to test that, we would really appreciate it.

With DPCM when compr is used on FE side, the BE is still running as 'normal' PCM. It is expected that the be_substream->runtime on the BE is not NULL, for example some codec drivers expect to have the substream->runtime valid, to store configuration for example. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

In preparation for adding support for compressed offload support for IPC4, rename the current compress implementation with the IPC3 prefix. Introduce a new field in struct sof_ipc_pcm_ops to save the IPC-specific compressed ops pointer. This should be set when the component driver ops are assigned during SOF device probe. Expose a couple of common functions that will be used by both IPC-specific implementations and rename the compress.c file to ipc3-compress.c Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

These are common functions that will also be needed for the IPC4 compressed support. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

In order to reuse the pipeline triggering logic for compressed support with IPC4, modify the signature of the trigger and hw_free PCM IPC ops so that they can be reused. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

…ng stream After the host DMA IID is released, reset the curr_pos to 0 for a clean start for subsequent stream starts. This is not needed for PCM streams but for compressed streams. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

Add new ops in the struct snd_sof_ops for platform-specific ops for compresssed streams. Also, define and set them for the HDA platforms. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Co-developed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

The SOF_IPC4_MOD_INIT_DATA_ID_MODULE_DATA type within the module_init_ext area is module specific init data. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

…dules Add support for handling init_ext_module_data for process modules, which is going to be used by decoder and encoder type of process mdoules. The support is generic and it can be extended to other type of process modules or other module types than process with a small update of sof_ipc4_add_init_ext_module_data() function. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

…cm.c The support for compressed stream will also need to have access to the same information which is used for delay reporting for DAI data progression tracking. Make the necessary struct and functions to be available and premare them to be called without a valid substream. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

ujfalusi · 2026-01-14T12:26:09Z

I don't see these errors with gcc (GCC) 15.2.1 20251112 locally, hrm.

Set and define the compressed ops for IPC4. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Co-developed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

There is no need to select IPC3 and IPC4 along with INTEL_CNL as INTEL_CNL selects both. Similarly, INTEL_MTL selects IPC4, so there is no need to do that for LNL, PTL and NVL. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

Select SOF_COMPRESS for TGL and newer platforms, on Intel devices the compressed support is available with IPC4 only. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

Decoder and encoder modules fall under process modules in SOF. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Co-developed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

…g_params SOF_CODEC_INFO tuple holds information about the supported codecs for decode/encode. If present in the fw_config payload, make a copy of it and store it sof_ipc4_fw_data->codec_info to be used by the compressed code. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

Parse the codec_info from fw_config message if present and return the supported codecs by the booted firmware. If the codec_info is missing then only set the information regarding to fragment sizes, numbers. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

Calculate the byte_offset for pointer tstamp. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

Check in set_params that the codec is supported. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

DRAIN, PERTIAL_DRAIN and NEXT_TRACK are not supported by the SOF stack yet Can be squashed. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

dbaluta · 2026-01-19T10:38:31Z

Will test this on IMX platforms, but we are only using IPC3 so not sure how much it helps. I'm not working on moving IMX to IPC4 but it will take a while.

Will be back with the results asap.

ujfalusi · 2026-01-19T10:54:47Z

Will test this on IMX platforms, but we are only using IPC3 so not sure how much it helps. I'm not working on moving IMX to IPC4 but it will take a while.

@dbaluta, we want to make sure that we don't break iMX (IPC3) and we are on reverse grounds that we can only test the new IPC4 support.

Will be back with the results asap.

Thank you!

0 codec report from fw is like no codec_info, so assume supported. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

…w_config_params Commit needs to be rewritten accordingly: id=35 is SOF_IPC4_FW_CFG_SOF_INFO, which hold a tuple based information, including CODEC_INFO as sub-id=0 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

lgirdwood

LGTM, some minor opens, some rebasing/squashing probably needed.

lgirdwood · 2026-01-19T13:52:54Z

sound/soc/soc-pcm.c

+		if (!fe->fe_compr) {
+			be_substream->runtime = fe_substream->runtime;
+		} else {
+			be_substream->runtime = kzalloc(sizeof(*be_substream->runtime), GFP_KERNEL);


any reason why we dont allocate this in the same logic as non compressed i.e. to balance the conditional logic here

The FE is not a PCM, there we don't have runtime at all, but BE is running as a PCM.

lgirdwood · 2026-01-19T14:07:53Z

sound/soc/sof/ipc4-priv.h

+struct sof_ipc4_timestamp_info {
+	struct sof_ipc4_copier *host_copier;
+	struct sof_ipc4_copier *dai_copier;
+	u64 stream_start_offset;


Btw do we subtract any media header from our positions or does cplay need to include this ?

we don't and we don't need to, this is the offset when the first real audio data left the DSP.
The media header is eaten up if it is eaten up by the decoder and it does not matter what the data was.
In compr there is no relation between what the host copies and what is played out.

lgirdwood · 2026-01-19T14:10:14Z

sound/soc/sof/ipc4-compress.c

+
+	spcm->stream[dir].cstream = cstream;
+	spcm->stream[dir].posn.host_posn = 0;
+	spcm->stream[dir].posn.dai_posn = 0;


ok, I assume our dai position will exclude the header as that's not rendered, but host position may include header ? Just wondering if cplay cares.

we don't use the dai_posn in ipc4 and there is no meaning of header in this regard. The DAI is running in PCM mode.

lgirdwood · 2026-01-19T14:12:50Z

sound/soc/sof/ipc4-compress.c

+	/* unprepare and free the list of DAPM widgets */
+	sof_widget_list_unprepare(sdev, spcm, dir);
+
+	cancel_work_sync(&spcm->stream[dir].period_elapsed_work);


should be cancel_work_flush_sync() before we free the widgets ?

hrm, might be better, but this is where the compr has been already stopped and we just report elapsed to ALSA.
I'll take a look.

it is following how normal PCM is handled, I will leave it like this as well.

lgirdwood · 2026-01-19T14:17:46Z

sound/soc/sof/ipc4-compress.c

+	cstream->dma_buffer.dev.type = SNDRV_DMA_TYPE_DEV_SG;
+	cstream->dma_buffer.dev.dev = dev;
+
+	ret = snd_compr_malloc_pages(cstream, crtd->buffer_size);


Btw, is there any size refinement here like with PCMs or is cplay request taken as-is ?

That I'm not sure, but we place a limit on frag size and number in later patch.

lgirdwood · 2026-01-19T14:22:28Z

sound/soc/sof/ipc4-compress.c

+	/*
+	 * stream_start_offset is updated to memory window by FW based on
+	 * pipeline statistics and it may be invalid if host query happens before
+	 * the statistics is complete. And it will not change after the first initiailization.


may need a comment on whether header is included or not.

Header has no meaning in here, this is pure PCM data, exactly like normal PCMs, we count the samples played out.

lgirdwood · 2026-01-19T14:27:38Z

sound/soc/sof/ipc4-compress.c

+
+out:
+	caps->direction = cstream->direction;
+	caps->min_fragment_size = 3 * 1024;


based on any particular format ? Maybe worth a comment

gut feeling ;) I will add defines :D

ujfalusi and others added 9 commits January 14, 2026 13:52

ASoC: SOF: sof-audio: Expose a couple of functions

f087819

These are common functions that will also be needed for the IPC4 compressed support. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

ASoC: SOF: ipc4: Add definition of module data in init_ext object type

72243bc

The SOF_IPC4_MOD_INIT_DATA_ID_MODULE_DATA type within the module_init_ext area is module specific init data. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

ujfalusi force-pushed the peter/topic/ipc4_compr branch from cea54e7 to c3f4c47 Compare January 14, 2026 14:08

ranj063 and others added 10 commits January 14, 2026 16:09

ASoC: SOF: Add support for IPC4 compressed

dd7adfa

Set and define the compressed ops for IPC4. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Co-developed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

ASoC: SOF: Intel: Kconfig: Select compress support for TGL+ platforms

8146ab1

Select SOF_COMPRESS for TGL and newer platforms, on Intel devices the compressed support is available with IPC4 only. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

-- get_caps wip --

7139584

fixup! ASoC: SOF: ops: Add new platform-specific ops for compress

3211437

Calculate the byte_offset for pointer tstamp. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

fixup! ASoC: SOF: ipc4-compress: Implement get_caps callback

693829a

Check in set_params that the codec is supported. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

ASoC: SOF: ipc4-compress: Return -ENOTSUPP for not supported triggers

ad5b2c1

DRAIN, PERTIAL_DRAIN and NEXT_TRACK are not supported by the SOF stack yet Can be squashed. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

ujfalusi changed the title ~~ASoC: SOF: Initial support for IPCV4 compress offload~~ ASoC: SOF: Initial support for IPC4 compress offload Jan 19, 2026

ujfalusi added 2 commits January 19, 2026 13:57

fixup! ASoC: SOF: ipc4-compress: Implement get_caps callback

7f2d8d9

0 codec report from fw is like no codec_info, so assume supported. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

lgirdwood reviewed Jan 19, 2026

View reviewed changes

ASoC: SOF: Initial support for IPC4 compress offload #5647

Are you sure you want to change the base?

ASoC: SOF: Initial support for IPC4 compress offload #5647

Uh oh!

Conversation

ujfalusi commented Jan 14, 2026

Uh oh!

ujfalusi commented Jan 14, 2026

Uh oh!

dbaluta commented Jan 19, 2026

Uh oh!

ujfalusi commented Jan 19, 2026

Uh oh!

lgirdwood left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants