Mark Brown [Fri, 28 Oct 2022 19:23:31 +0000 (20:23 +0100)]
ASoC: qdsp6: audioreach: add multi-port, SAL and MFC support
Merge series from Srinivas Kandagatla <srinivas.kandagatla@linaro.org>:
This patchset adds support to multi-port connections between AudioReach Modules
which is required for sophisticated graphs like ECNS or Speaker Protection.
Also as part of ECNS testing new module support for SAL and MFC are added.
Mark Brown [Fri, 28 Oct 2022 18:52:20 +0000 (19:52 +0100)]
ASoC: SOF: Intel: HDA: refactor codec and multi-link suport
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>:
Existing HDaudio controllers expose an HDAudio DMA which is used to
interface with HDaudio codecs. All other interfaces supported by Intel
(SoundWire, SSP, DMIC) rely for data transfers on another GP-DMA
managed by the DSP firmware - the HDaudio DMA is only used for
memory-to-DSP transfers.
New HDaudio extensions will enable the use of this HDaudio DMA for all
of SoundWire, SSP, DMIC. These extensions will be backwards-compatible
for HDaudio and iDISP codecs, but will require new programming
sequences and DAI callbacks for SoundWire, SSP and DMIC.
Before we add support for 'extended audio links' and the programming
sequences for the DMA, we need to refactor the code. All HDaudio codec
support needs to be well identified in a separate file, and likewise
all the 'multi-link' handling needs to be better split.
This patchset removes a number of 'old' Kconfig dependencies and
options, adds helpers with a fallback to remove IS_ENABLED checks in
the code and tries to simplify programming sequences when possible.
One indirect benefit from this refactoring is that developers can
switch with a kernel parameter from HDaudio support to a variant of
'nocodec' support. This proves extremely useful to test on existing
Intel RVPs and Up boards, where the same build can be used to check 3
interfaces (HDaudio, SSP, DMIC) by just removing modules, setting the
kernel parameter and reloading modules.
Mark Brown [Fri, 28 Oct 2022 16:40:22 +0000 (17:40 +0100)]
ASoC: Intel: avs: PCM power management
Merge series from Cezary Rojewski <cezary.rojewski@intel.com>:
Goal of the series is implementation of suspend/resume operations for a
PCM stream along with all the collaterals connected to the subject.
Start with splitting avs_dai_fe_hw_free() as ideally we would like to
reuse as much of existing code as possible but snd_pcm_lib_free_pages()
is not desired part of the function when speaking of suspend operation.
The actual implementation of suspend/resume() for component drivers
follows. For most scenarios, the PM flow is similar to standard
streaming one, except for the part where the position register are being
saved and the lack of PCM pages freeing. To reduce code duplication, all
avs_dai_suspend_XXX() and avs_dai_resume_XXX() functions reuse their
non-PM equivalents.
Order of operations is affected by the fact that path binding/unbinding
happens only in FE part of the stream.
Above essentially unlocks SX+streaming scenarios i.e.: power transitions
with an ongoing stream.
As some streams are allowed to run in low power state, support is
provided for S0iX state. The handlers check ACPI capabilities and the
number of active low-power paths before deciding between SX and S0iX
flows.
The last portion of the patchset is addition of power/clock gating
overrides. There is no single set of registers that ensures AudioDSP
firmware loads 100% of time on every single configuration. By having
them exposed, user can have the loading procedure behavior adjusted for
their configuration without having to recompile the kernel.
ASoC: qdsp6: audioreach: add support for more port connections
AudioReach Modules can connect to other modules using source and
destination port, and each module in theory can support up to 255 port
connections. But in practice this limit is at max 8 ports at a time.
So add support for allowing multiple port connections.
This support is needed for more detailed graphs like ECNS, speaker
protection and so.
ASoC: qdsp6: audioreach: Simplify handing FE and BE graph connections
Current AudioReach design of connecting FE and BE graph is very complicated
and not reliable. Instead used the virtual damp widgets private data to help
identify the modules that needs connection at runtime. Also maintain a
inter-graph connection info in the graph info, which can be used to both
determine if the graphs are connected and at graph build time.
ASoC: qdsp6: audioreach: update dapm kcontrol private data
Update kcontrol private date to include more information like graph id
and module instance id which its connected to. Also maintain this virtual
dapm mixer widget in a list so that we could lookup while FE and BE connection
are added.
The existing NOCODEC mode enforces a build-time mutual exclusion with
the HDaudio link support, mostly to avoid any dependency on the
snd_hdac library and references to HDAudio codec/i915 stuff.
This is very useful to track dependencies and test a minimal
configuration, but very painful for developers and CI: a recompilation
and reinstall of the kernel modules is required.
This patch suggests an alternate middle ground where the selection of
the machine driver and all codec-related actions are bypassed at
run-time, contingent on a kernel module parameter being set.
For example setting BIT(10) with
'options snd_sof sof_debug=0x401'
is enough to switch from an HDaudio card to a nocodec one.
This new DEBUG_NOCODEC mode is not suitable for distributions and
end-users. It's not even recommended on all platforms, i.e. the
NOCODEC mode is known not to work on specific devices where the BIOS
did not configure support for I2S/DMIC interfaces. The usual
development devices such as Chromebooks, Up boards and Intel RVP are
the only recommended platforms where this mode can be supported.
Note that the dynamic switch between HDaudio and nocodec may not
always possible depending on hardware layout, pin-mux options, and
BIOS settings. The audio subsustems on Intel platforms has to support
4 types of interfaces and pin-mux can be complicated.
Reviewers might ask: why didn't we do this earlier? The main reason is
that all the codec-related configurations were not cleanly separated
out in the sof/intel directory. With all the cleanups done recently,
adding this opt-in behavior is relatively straightforward.
Tested on UpExtreme (WHL) and UpExtreme i11 (TGL).
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20221027193540.259520-22-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: SOF: Intel: hda-codec: use GPL-2.0-only license
All the HDAudio codec handling is completely specific to Linux and
completely dependency on GPL2.0 code, specifically the snd_hdac_
library.
There was no intention to have a dual-license for this code, this was
an oversight that needs to be corrected. Update the SPDX and
EXPORT_SYMBOL information, no functionality change otherwise.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20221027193540.259520-21-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
There is no real reason to filter out this allocation at build
time. Let's allocate it always, so that we can have a more dynamic way
of disabling HDaudio codec support without having to recompile.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20221027193540.259520-12-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Cezary Rojewski [Thu, 27 Oct 2022 12:47:02 +0000 (14:47 +0200)]
ASoC: Intel: avs: Enact power gating policy
Update all firmware loading functions to also account for the power
gating policy. As module loading routine is missing the chicken bits
manipulation entirely, add the entire set there.
Cezary Rojewski [Thu, 27 Oct 2022 12:47:01 +0000 (14:47 +0200)]
ASoC: Intel: avs: Power and clock gating policy overriding
Provide pgctl/cgctl_mask module parameters for overriding power and
clock gating policies respectively. These help deal with rare firmware
loading failures on some configurations. There're no golden masks that
cover all known problems so leave the defaults as is.
While at it, update avs_hda_l1sen_enable()'s definition so it aligns
with its power/clock friends.
Piotr Maziarz [Thu, 27 Oct 2022 12:47:00 +0000 (14:47 +0200)]
ASoC: Intel: avs: Standby power-state support
Introduce avs_suspend_standby() and avs_resume_standby() to support S0IX
streaming. The AudioDSP is not shutdown during such scenario and the PCI
device is armed for possible wake operation through an audio event.
As capability for a stream to be active during low power S0 is based off
of ->ignore_suspend, adjust the field's value according to platform
capabilities if needed.
Cezary Rojewski [Thu, 27 Oct 2022 12:46:58 +0000 (14:46 +0200)]
ASoC: Intel: avs: Restart instead of resuming HDA capture streams
Resuming of capture streams for HD-Audio is unsupported so remove the
relevant flag from the hardware params when assigning them during
avs_component_hda_open().
Cezary Rojewski [Thu, 27 Oct 2022 12:46:56 +0000 (14:46 +0200)]
ALSA: hda: Introduce snd_hdac_stream_wait_drsm()
Allow for waiting for DRSM bit for specified stream to be cleared from
HDAudio library level. Drivers may utilize this optional step during the
stream resume procedure.
Suggested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20221027124702.1761002-4-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Cezary Rojewski [Thu, 27 Oct 2022 12:46:55 +0000 (14:46 +0200)]
ASoC: Intel: avs: Introduce PCM power management routines
Implement suspend/resume() operations for component drivers. For most
scenarios, the PM flow is similar to standard streaming one, except for
the part where the position register are being saved and the lack of PCM
pages freeing. To reduce code duplication, all avs_dai_suspend_XXX() and
avs_dai_resume_XXX() functions reuse their non-PM equivalents.
Given that path binding/unbinding happens only in FE part of the stream,
the order of suspend() goes:
1. hw_free() all FE DAIs, paths are unbound here
2. hw_free() all BE DAIs
Consequently, for resume() its:
1. hw_params() all BE DAIs
2. hw_params() all FE DAIs, paths are bound here
3. prepare() all BE DAIs
4. prepare() all FE DAIs
As component->suspend/resume() do not provide substream pointer, store
it ourselves so that the PM flow has all the necessary information to
proceed.
Cezary Rojewski [Thu, 27 Oct 2022 12:46:54 +0000 (14:46 +0200)]
ASoC: Intel: avs: Split pcm pages freeing operation from hw_free()
Prepare for introduction of PCM power management support. As freeing
pages during the suspend operation is not desired, separate
snd_pcm_lib_free_pages() from existing avs_dai_fe_hw_free() so that
majority of the code found within it can be reused for standard and PM
flows both.
Shengjiu Wang [Fri, 28 Oct 2022 07:03:47 +0000 (15:03 +0800)]
ASoC: fsl_xcvr: Add Counter registers
These counter registers are part of register list,
add them to complete the register map
- DMAC counter control registers
- Data path Timestamp counter register
- Data path bit counter register
- Data path bit count timestamp register
- Data path bit read timestamp register
Chancel Liu [Thu, 27 Oct 2022 06:03:11 +0000 (14:03 +0800)]
ASoC: fsl_sai: Specify the maxburst to 8 on i.MX93 platform
There is a limit to eDMA AXI on i.MX93. Only TCD that has NBYTES in a
multiple of 8bytes can enable scatter-gather. NBYTES is calculated by
bus width times maxburst. On i.MX93 platform the value of maxburst is
specified to 8. It makes sure that NBYTES is a multiple of 8bytes.
Chancel Liu [Thu, 27 Oct 2022 06:03:09 +0000 (14:03 +0800)]
ASoC: dt-bindings: fsl,sai: Add compatible string for i.MX93 platform
Add compatible string "fsl,imx93-sai" for i.MX93 platform
Signed-off-by: Chancel Liu <chancel.liu@nxp.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://lore.kernel.org/r/20221027060311.2549711-2-chancel.liu@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
Mark Brown [Wed, 26 Oct 2022 18:53:14 +0000 (19:53 +0100)]
ASoC: SOF: Intel: HDaudio cleanups
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>:
This is the part1 of my HDaudio cleanups, before the addition of
to-be-announced HDaudio extensions.
The patchset includes more consistent use of read/write/update
helpers, removal of useless waits, structure members and programming
sequences, removal of confusing sharing of private_data between FE and
BE.
Additional patches are coming to split the controller, codec and
multi-link management functionality in well-identified files.
Pierre-Louis Bossart (16):
ASoC: SOF: ops: fallback to mmio in helpers
ASoC: SOF: Intel: use mmio fallback for all platforms
ASoC: SOF: ops: add readb/writeb helpers
ASoC: SOF: ops: add snd_sof_dsp_updateb() helper
ASoC: SOF: Intel: hda-dsp: use SOF helpers for consistency
ASoC: SOF: Intel: hda-dai: start removing the use of
runtime->private_data in BE
ASoC: SOF: Intel: hda-dai: use component_get_drvdata to find hdac_bus
ASoC: SOF: Intel: hda-dai: remove useless members in hda_pipe_params
ASoC: SOF: Intel: hda-ctrl: remove useless sleep
ASoC: SOF: Intel: hda: always do a full reset
ASoC: SOF: Intel: hda: remove useless check on GCTL
ASoC: SOF: Intel: hda-stream: use SOF helpers for consistency
ASoC: SOF: Intel: hda-stream: rename CL_SD_CTL registers as SD_CTL
ASoC: SOF: Intel: hda: use SOF helper for consistency
ASoC: SOF: Intel: hda-stream: use snd_sof_dsp_updateb() helper
ASoC: SOF: Intel: hda-stream: use readb/writeb for stream registers
Mark Brown [Wed, 26 Oct 2022 18:29:28 +0000 (19:29 +0100)]
ASoC: cleanups and improvements for jz4740-i2s
Merge series from Aidan MacDonald <aidanmacdonald.0x0@gmail.com>:
This series is a preparatory cleanup of the jz4740-i2s driver before
adding support for a new SoC. The two improvements are lifting
unnecessary restrictions on sample rates and formats -- the existing
ones appear to be derived from the limitations of the JZ4740's internal
codec and don't reflect the actual capabilities of the I2S controller.
I'm unable to test the series on any JZ47xx SoCs, but I have tested
on an X1000 (which is the SoC I'll be adding in a followup series).
ASoC: dt-bindings: rt5682: Set sound-dai-cells to 1
Commit 0adccaf1eac9 ("ASoC: dt-bindings: rt5682: Add #sound-dai-cells")
defined the sound-dai-cells property as 0. However, rt5682 has two DAIs,
AIF1 and AIF2, and therefore should have sound-dai-cells set to 1. Fix
it.
Fixes: 0adccaf1eac9 ("ASoC: dt-bindings: rt5682: Add #sound-dai-cells") Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20221024220015.1759428-4-nfraprado@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
The rt5682s codec is a DAI provider with two interfaces - AIF1 and AIF2
- and therefore should have a #sound-dai-cells property that is equal to
1. Add it.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20221024220015.1759428-2-nfraprado@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
Peter Ujfalusi [Tue, 25 Oct 2022 13:27:06 +0000 (16:27 +0300)]
ASoC: SOF: ipc4-loader: Return ssize_t from sof_ipc4_fw_parse_ext_man()
sof_ipc4_fw_parse_ext_man() can return negative error numbers which is not
correct for the used size_t type.
Change the return value to ssize_t and use the same type where the function
is called.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: 73c091a2fe96 ("ASoC: SOF: ipc4-loader: Support for loading external libraries") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20221025132706.30356-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: dt-bindings: mt8192-mt6359: Set maxItems, not type, for sound-dai
sound-dai is a standard property whose type is already set to
phandle-array by sound-dai.yaml, so there's no need to set it (and
wrongly so for headset-codec) in this binding. What should be set
however is the maximum number of items, which for headset-codec should
be 1.
Aidan MacDonald [Sun, 23 Oct 2022 14:33:28 +0000 (15:33 +0100)]
ASoC: jz4740-i2s: Refactor DAI probe/remove ops as component ops
Move most of the DAI probe/remove logic into component ops.
This makes things more consistent because the AIC clock is
now managed solely from the component side. And it makes it
easier to add codec switching support later on.
Aidan MacDonald [Sun, 23 Oct 2022 14:33:26 +0000 (15:33 +0100)]
ASoC: jz4740-i2s: Support continuous sample rate
The I2S controller on JZ47xx SoCs doesn't impose restrictions on
sample rate and the driver doesn't make any assumptions about it,
so the DAI should advertise a continuous sample rate range.
Aidan MacDonald [Sun, 23 Oct 2022 14:33:25 +0000 (15:33 +0100)]
ASoC: jz4740-i2s: Support S20_LE and S24_LE sample formats
The audio controller on JZ47xx SoCs can transfer 20- and 24-bit
samples in the FIFO, so allow those formats to be used with the
I2S driver. Although the FIFO doesn't care about the in-memory
sample format, we only support 4-byte format variants because the
DMA controller on these SoCs cannot transfer in 3-byte multiples.
Aidan MacDonald [Sun, 23 Oct 2022 14:33:22 +0000 (15:33 +0100)]
ASoC: jz4740-i2s: Simplify using regmap fields
The differences between register fields on different SoC versions
can be abstracted away using the regmap field API. This is easier
to understand and extend than comparisons based on the version ID.
Since the version IDs are unused after this change, remove them at
the same time, and remove unused macros.
Aidan MacDonald [Sun, 23 Oct 2022 14:33:21 +0000 (15:33 +0100)]
ASoC: jz4740-i2s: Convert to regmap API
Using regmap for accessing the AIC registers makes the driver a
little easier to read, and later refactors can take advantage of
regmap APIs to further simplify the driver.
On the JZ4740, there is a single bit that flushes (empties) both
the transmit and receive FIFO. Later SoCs have independent flush
bits for each FIFO.
Independent FIFOs can be flushed before the snd_soc_dai_active()
check because it won't disturb other active streams. This ensures
that the FIFO we're about to use is always flushed before starting
up. With shared FIFOs we can't do that because if another substream
is active, flushing its FIFO would cause underrun errors.
This also fixes a bug: since we were only setting the JZ4740's
flush bit, which corresponds to the TX FIFO flush bit on other
SoCs, other SoCs were not having their RX FIFO flushed at all.
Fixes: 967beb2e8777 ("ASoC: jz4740: Add jz4780 support") Reviewed-by: Paul Cercueil <paul@crapouillou.net> Cc: stable@vger.kernel.org Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20221023143328.160866-2-aidanmacdonald.0x0@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: SOF: Intel: hda-stream: rename CL_SD_CTL registers as SD_CTL
The use of the CL prefix is misleading. HDaudio streams are used for
code loading since ApolloLake, but they are also used for regular
audio transfers.
ASoC: SOF: Intel: hda-dai: start removing the use of runtime->private_data in BE
The SOF HDAudio code stores the Host DMA hdac_stream structure in the
FE substream->runtime->private_data. The BE dailink also uses the
substream->runtime->private_data to allocate the link DMA stream tag.
This really works by accident: the DPCM core copies the FE runtime
information in the BE, which has the side-effect of sharing the
FE-specific private_data with the BE.
To avoid more uses of the private_data with potential issues such as
accessing stale information or use-after-free cases, this patch
removes most of the usages of this private_data at the BE level. We
can directly use the existing dma_data to access the relevant
information.
However the hw_params still uses the information, mainly to go back to
the 'bus' structure required for the link dma stream tag
allocation. This is safe in that the 'bus' is not stream or PCM
specific.
The next patch will completely remove this last use of private_data by
using the component_drvdata - which is how SOF passes a global context
around.
Returning an error when a read/write is not implemented makes no
sense, especially on read where no return value makes sense.
Change the logic to directly fallback to mmio. If a platform truly
wants other read/writes that are not plain vanilla mmio, it needs to
implement its own routines.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20221024165310.246183-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Mark Brown [Fri, 21 Oct 2022 19:04:19 +0000 (20:04 +0100)]
ASoC: SOF: Intel/IPC4: Support for external firmware libraries
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:
Peter Ujfalusi [Thu, 20 Oct 2022 12:12:33 +0000 (15:12 +0300)]
ASoC: SOF: Intel: hda: Add flag to indicate that the firmware is IMR booted
Dynamic loading of external libraries should not be done if the firmware
was booted from IMR since in that case the libraries will be restored along
with the basefw.
The booted_from_imr flag is introduced and set to true if the IMR boot was
successful and to false if cold booting is executed.
The reason for the new flag is that guessing from existing flags, used to
decide if we should try booting from IMR or not is not going to be robust
as the IMR boot itself can fail and in that case a full, cold boot is
executed.
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-15-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Peter Ujfalusi [Thu, 20 Oct 2022 12:12:30 +0000 (15:12 +0300)]
ASoC: SOF: Add path definition for external firmware libraries
IPC4 based firmware supports dynamically loaded external libraries.
The libraries will be not stored alongside of the firmware or tplg files.
For intel platforms the default path will be:
intel/avs-lib|sof-ipc4-lib/<platform>/ if a community key is used on the
given machine then the libraries will be under 'community' directory, like
it is done for the firmware itself.
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-12-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Peter Ujfalusi [Thu, 20 Oct 2022 12:12:29 +0000 (15:12 +0300)]
ASoC: SOF: IPC4: Add helper for looking up module by UUID
Add a simple helper to walk the loaded libraries and their modules to make
the ipc4-topology not aware of the underlying infrastructure and simplify
the code.
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-11-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Peter Ujfalusi [Thu, 20 Oct 2022 12:12:28 +0000 (15:12 +0300)]
ASoC: SOF: ipc4: Convert the firmware handling (loader) to library convention
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>
Peter Ujfalusi [Thu, 20 Oct 2022 12:12:27 +0000 (15:12 +0300)]
ASoC: SOF: ipc4-loader: Save the maximum number of libraries supported
The firmware supports external libraries (containing modules) to be loaded
runtime.
The firmware configuration contains the maximum number of libraries
supported, including the base firmware (which is library 0).
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-9-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
projects / thirdparty / linux.git / log
