Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
In IPC4 all DSP loadable executable is a 'library' containing modules. The main
or basefw is also a library which contains multiple modules.
IPC4 allows to use loadable libraries to extend the functionality of the booted
basefw.
This series adds support for loading external libraries in case they are needed
by the loaded topology file.
The libraries must be placed to a specific firmware directory (fw_lib_prefix),
which is:
intel/avs-lib|sof-ipc4-lib/ followed by the platform name and in case of
community key use a 'community' directory.
For example for upx-i11 (community key): intel/avs-lib/tgl/community is the
default path.
The name of the library should be the UUID of the module it contains since the
library loading is going to look for the file as <module_UUID>.bin
In case there is a need to bundle multiple modules into single library, symlinks
can be used to point to the file:
module_boundle.bin
<UUID1>.bin -> module_boundle.bin
<UUID2>.bin -> module_boundle.bin
<UUID3>.bin -> module_boundle.bin
But note that in this case all modules will be loaded to the DSP since only the
whole library can be loaded, not individual modules.
With IPC4 each DSP loadable binary is a library, which contains
ext_manifest section and loadable modules.
The basefw is no exception, it is always library 0 and it can contain
several modules, depending on the firmware build.
The current code assumes only one binary, which is the basefw and has no
concept of libraries.
This patch introduces the library+modules abstraction and represents the
basefw as library for the IPC4 loader codebase.
The basefw loading and handling is not changing, it is still done by the
generic code, but it's information is cloned under the library
representation.
The libraries are managed via XArray to offload the list and ID management.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Chao Song <chao.song@intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20221020121238.18339-10-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The SPIB and DRMS capabilities are orthogonal to the DSP enablement
and can be used whether the stream is coupled or not.
The existing code partitioning makes limited sense, the capabilities
are parsed at the sound/hda level but helpers are located in
sound/hda/ext.
This patch moves all the SPIB/DRMS functionality to the sound/hda
layer. This reduces the complexity of the sound/hda/ext layer which is
now limited to handling the multi-link extensions and stream
coupling/decoupling helpers.
Note that this is an iso-functionality code move and rename, the
HDaudio legacy driver would need additional changes to make use of
these capabilities.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20221019162115.185917-11-pierre-louis.bossart@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
My esteemed colleagues keep using the same words for different things.
The multi-link structure needs to be handled whether the DSP is
enabled or not.
The host and link DMAs are only relevant when the DSP is enabled.
Things get convoluted when there's an ambiguity between the LOSIDV
settings in the multi-link register space and the selection of the
stream_tag for the link DMA.
Clarify with a rename that the static functions used are related to
the host and link DMAs only.
No functionality change, pure rename.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20221019162115.185917-9-pierre-louis.bossart@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>:
These are v2 of random cleanup for soc-dpam.c/h.
Basically, these are just cleanup, nothing changed.
Merge series from Siarhei Volkau <lis8215@gmail.com>:
The patchset fixes:
- Line In path stays powered off during capturing or
bypass to mixer.
- incorrectly represented dB values in alsamixer, et al.
- incorrect represented Capture input selector in alsamixer
in Playback tab.
- wrong control selected as Capture Master
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
Hi,
The IPC4 use of doorbell registers leaves some corner cases not well defined
and the 'correct sequences' are subjective in a sense.
The DSP doorbell registers are used as separate and independent channels and
the sequences for host -> DSP -> host (reply) can be racy.
For example:
The ACKing of a received message can happen before the firmware sends the reply
or it can as well happen after the reply has been sent and received by the host.
Both can be considered 'correct sequences' but they need different handling.
This series will allow the kernel to service any interpretation of the
sequencing on the firmware side.
The "convert-xxx" properties only have an effect for DPCM DAI links.
A DAI link is only created as DPCM if the device tree requires it;
part of this involves checking for the use of "convert-xxx" properties.
When the convert-sample-format property was added, the checks got out
of sync. A DAI link that specified only convert-sample-format but did
not pass any of the other DPCM checks would not go into DPCM mode and
the convert-sample-format property would be silently ignored.
Fix this by adding a function to do the "convert-xxx" property checks,
instead of open-coding it in simple-card and audio-graph-card. And add
"convert-sample-format" to the check function so that DAI links using
it will be initialized correctly.
Fixes: 047a05366f ("ASoC: simple-card-utils: Fixup DAI sample format")
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com>
Acked-by: Sameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/20221019012302.633830-1-aidanmacdonald.0x0@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Current soc-pcm.c is coping fe hw_param to dpcm->hw_param (A),
fixup it (B), and copy it to be (C).
int dpcm_be_dai_hw_params(...)
{
...
for_each_dpcm_be(fe, stream, dpcm) {
...
/* copy params for each dpcm */
(A) memcpy(&dpcm->hw_params, &fe->dpcm[stream].hw_params, ...) ;
/* perform any hw_params fixups */
(B) ret = snd_soc_link_be_hw_params_fixup(be, &dpcm->hw_params);
...
/* copy the fixed-up hw params for BE dai */
(C) memcpy(&be->dpcm[stream].hw_params, &dpcm->hw_params, ...);
...
}
...
}
But here, (1) it is coping hw_params without caring stream (Playback/Capture),
(2) we can get same value from be. We don't need to have dpcm->hw_params.
This patch removes it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/87v8ogsl6h.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The comment of snd_soc_dapm_widget_for_each_path() (= X) has
"_sink_" (= s), but this is typo.
With "_sink_" is already exist at (A). This patch fixup it.
/**
(s) * snd_soc_dapm_widget_for_each_sink_path - ...
* ****
*/
(X) #define snd_soc_dapm_widget_for_each_path(w, dir, p)
/**
(s) * snd_soc_dapm_widget_for_each_sink_path_safe - ...
* ****
*/
(X) #define snd_soc_dapm_widget_for_each_path_safe(w, dir, p, next_p)
(A) #define snd_soc_dapm_widget_for_each_sink_path(w, p)
****
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/87wn8wsl6n.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
snd_soc_dapm_new_dai() setups local variable "template" at (X) and (Y),
which is used at (Z). But these are difficult to read.
static struct snd_soc_dapm_widget * snd_soc_dapm_new_dai()
{
...
^ template.reg = ...
| template.id = ...
(X) template.name = ...
| template.event = ...
| template.event_flags = ...
v template.kcontrol_news = ...
if (rtd->dai_link->num_params > 1) {
...
^ template.num_kcontrols = ...
(Y) template.kcontrol_news = ...
v ...
}
...
(Z) w = snd_soc_dapm_new_control_unlocked(..., &template);
}
And this function has error message, but not for all cases.
This patch (1) setups "template" in one place, and indicate error message
for all cases. This patch cleanup the code, but nothing changed for
meaning.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/871qr4tzro.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
dapm_widget_set_power() (= X) is called only from
dapm_power_one_widget() (= Y), and total purpose of these functions are
calling dapm_seq_insert() (= a) accordingly for each widget.
(X) static void dapm_widget_set_power(...)
{
...
if (power)
(a) dapm_seq_insert(w, up_list, true);
else
(a) dapm_seq_insert(w, down_list, false);
}
(Y) static void dapm_power_one_widget(...)
{
..
switch (w->id) {
case snd_soc_dapm_pre:
(a) dapm_seq_insert(w, down_list, false);
break;
case snd_soc_dapm_post:
(a) dapm_seq_insert(w, up_list, true);
break;
default:
power = dapm_widget_power_check(w);
(X) dapm_widget_set_power(w, power, up_list, down_list);
break;
}
}
It should be more simple, but the code is unnecessarily complicated,
and difficult to read/understand. This patch merge these into one.
Link: https://lore.kernel.org/all/87tu42owdd.wl-kuninori.morimoto.gx@renesas.com/
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/8735bktzrx.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
