linux-toradex.git/sound/soc/sof/ipc4-topology.c, branch v6.11-rc3

ASoC: SOF: ipc4-topology: Preserve the DMA Link ID for ChainDMA on unprepare

2024-07-24T10:29:13+00:00

The DMA Link ID is set to the IPC message's primary during dai_config,
which is only during hw_params.
During xrun handling the hw_params is not called and the DMA Link ID
information will be lost.

All other fields in the message expected to be 0 for re-configuration, only
the DMA Link ID needs to be preserved and the in case of repeated
dai_config, it is correctly updated (masked and then set).

Cc: stable@vger.kernel.org
Fixes: ca5ce0caa67f ("ASoC: SOF: ipc4/intel: Add support for chained DMA")
Link: https://github.com/thesofproject/linux/issues/5116
Signed-off-by: Peter Ujfalusi 
Reviewed-by: Bard Liao 
Reviewed-by: Ranjani Sridharan 
Reviewed-by: Pierre-Louis Bossart 
Link: https://patch.msgid.link/20240724081932.24542-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: ipc4-topology: Only handle dai_config with HW_PARAMS for ChainDMA

2024-07-24T10:29:12+00:00

The DMA Link ID is only valid in snd_sof_dai_config_data when the
dai_config is called with HW_PARAMS.

The commit that this patch fixes is actually moved a code section without
changing it, the same bug exists in the original code, needing different
patch to kernel prior to 6.9 kernels.

Cc: stable@vger.kernel.org
Fixes: 3858464de57b ("ASoC: SOF: ipc4-topology: change chain_dma handling in dai_config")
Link: https://github.com/thesofproject/linux/issues/5116
Signed-off-by: Peter Ujfalusi 
Reviewed-by: Bard Liao 
Reviewed-by: Ranjani Sridharan 
Reviewed-by: Pierre-Louis Bossart 
Link: https://patch.msgid.link/20240724081932.24542-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: ipc4-topology: Use single token list for the copiers

2024-07-04T11:42:23+00:00

There is no need to keep separate token list for dai and 'common' copier
token list when the 'common' list is actually the aif list, the
SOF_COPIER_DEEP_BUFFER_TOKENS are not applicable for buffers.

We could have separate lists for all types but it is probably simpler to
just use a single list for all types of copiers. Function specific tokens
will be only parsed by function specific code anyways.

Reviewed-by: Bard Liao 
Reviewed-by: Ranjani Sridharan 
Signed-off-by: Peter Ujfalusi 
Signed-off-by: Pierre-Louis Bossart 
Link: https://patch.msgid.link/20240704085944.371450-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: ipc4-topology: Use correct queue_id for requesting input pin format

2024-06-24T12:38:33+00:00

It is incorrect to request the input pin format of the destination widget
using the output pin index of the source module as the indexes are not
necessarily matching.
moduleA.out_pin1 can be connected to moduleB.in_pin0 for example.

Use the dst_queue_id to request the input format of the destination module.

This bug remained unnoticed likely because in nocodec topologies we don't
have process modules after a module copier, thus the pin/queue index is
ignored.
For the process module case, the code was likely have been tested in a
controlled way where all the pin/queue/format properties were present to
work.

Update the debug prints to have better information.

Reviewed-by: Kai Vehmanen 
Reviewed-by: Ranjani Sridharan 
Reviewed-by: Bard Liao 
Signed-off-by: Peter Ujfalusi 
Signed-off-by: Pierre-Louis Bossart 
Cc: stable@vger.kernel.org # v6.8+
Link: https://patch.msgid.link/20240624121519.91703-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown

ASoC: Merge up fixes

2024-06-03T11:45:04+00:00

We need this to get the i.MX platforms working in CI again.

ASoC: SOF: ipc4-topology: Fix nhlt configuration blob

2024-05-30T13:33:14+00:00

Merge series from Peter Ujfalusi :

The existing logic to pick a DMIC blob is based on several historical
assumptions that the NHLT in BIOS always contains 32-bits per sample
type (first patch, [1]).

The other issue with the existing logic is that it was designed to care only
about the bit depth of the format and fails to find the existing and correct
blob when rate/channels are different on the FE side compared to what we should
be using on the DAI side (we have components in path which can change
rate/channel count).

These issues have not been observed in past but with new MTL based (Windows)
laptops and new topologies to enhance the audio quality, we started to see weird
issues around how our assumptions of vendors failed.

Since some NHLT blob handling cleanup has been done for 6.10, this series will
complete that work to cover even cases that we don't anticipate to see.

[1] https://github.com/thesofproject/linux/issues/4973

ASoC: SOF: ipc4-topology: Adjust the params based on DAI formats

2024-05-30T11:33:32+00:00

Currently we only check the bit depth value among to DAI formats, but other
parameters might be constant, like number of channels and/or rate.

In capture we use the fe params as a reference to find the format and blob
which should be used, but in the path we can have components which can
handle expanding/narrowing number of channels or do a resample.

In these cases the topology is expected to have 'fixed' parameter for
channels/rates/bit depth and the conversion to the fe format is going to
be done within the path.

In practice this patch fixes issues like:
All DMIC formats are fixed four channels
We have a component which converts the four channel to stereo
FE is opened with 2 channel

Even if we have the correct bit depth format and blob (for four channel) we
will still be looking for stereo configurations, which will fail.

Note: the adjustment of params have switched order with the checking of
single bit depth (needed for the NHLT blob fallback support). This change
is non function, just that if the sof_ipc4_narrow_params_to_format() would
fail, there is no point of checking the single bit depth.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Pierre-Louis Bossart 
Reviewed-by: Bard Liao 
Reviewed-by: Seppo Ingalsuo 
Reviewed-by: Ranjani Sridharan 
Link: https://msgid.link/r/20240530111918.21974-6-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: ipc4-topology: Improve readability of sof_ipc4_prepare_dai_copier()

2024-05-30T11:33:31+00:00

Remove the duplicated code paths to check for single bit depth and to
update the params with storing the parameters needed by the function and
have a single code section.

No functional change but the code is easier to follow.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Pierre-Louis Bossart 
Reviewed-by: Bard Liao 
Reviewed-by: Seppo Ingalsuo 
Reviewed-by: Ranjani Sridharan 
Link: https://msgid.link/r/20240530111918.21974-5-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: ipc4-topology/pcm: Rename sof_ipc4_copier_is_single_format()

2024-05-30T11:33:30+00:00

Rename the sof_ipc4_copier_is_single_format() to
sof_ipc4_copier_is_single_bitdepth() to clear the confusion of the use of
'format' when we are querying information on the bit depth.
Format is used to describe a combination of parameters (rate, channels,
sample format / bit depth).
Rename the flags used to store the result at the same time.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Pierre-Louis Bossart 
Reviewed-by: Bard Liao 
Reviewed-by: Seppo Ingalsuo 
Reviewed-by: Ranjani Sridharan 
Link: https://msgid.link/r/20240530111918.21974-4-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown

ASoC: SOF: ipc4-topology: Print out the channel count in sof_ipc4_dbg_audio_format

2024-05-30T11:33:29+00:00

Print out the number of channels for the format explicitly instead of
having the reader to understand how to interpret the ch_map and ch_cfg
values.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Pierre-Louis Bossart 
Reviewed-by: Ranjani Sridharan 
Reviewed-by: Bard Liao 
Link: https://msgid.link/r/20240530111918.21974-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown