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.
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.
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.
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.
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.
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).
Peter Ujfalusi [Thu, 20 Oct 2022 12:12:21 +0000 (15:12 +0300)]
ASoC: SOF: Introduce container struct for SOF firmware
Move the firmware related information under a new struct (sof_firmware)
and add it to the high level snd_sof_dev struct.
Convert the generic code to use this new container when working with the
basefw and for compatibility reasons set the old plat_data members used by
the platforms.
ASoC: SOF: loader: Set complete state before post_fw_run op
Set the FW state to complete right after boot is complete. This enables
sending IPC's in the post_fw_run op. This will be needed to support
reloading 3rd party module libraries after firmware boot.
ALSA/ASoC: hda: move SPIB/DRMS functionality from ext layer
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.
commit 0b00a5615dc40 ("ALSA: hdac_ext: add hdac extended controller")
introduced a for() loop on the number of HDaudio codecs that seems
completely useless.
a) the body of the loop does not make use of the loop index, and
b) the LSDIID register is related to the SDI line, so there can only
be one codec per multi-link descriptor.
ALSA: hda: ext: reduce ambiguity between 'multi-link' and 'link' DMA
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.
ALSA/ASoC: hda: ext: add 'bus' prefix for multi-link stream setting
All the helpers dealing with multi-link configurations are located in
the hdac_ext_controller.c, except the two set/clear routines that
modify the LOSIDV registers.
For consistency, move the two helpers and add the 'bus' prefix. One
could argue that the 'ml' prefix might be more relevant but that would
be a larger code change.
ALSA/ASoC: hda: ext: remove 'link' prefix for stream-related operations
We should only use 'link' in the context of multi-link
configurations. Streams are configured from a different register space
and are not dependent on link except for LOSIDV settings.
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
ASoC: amd: acp: Add setbias level for rt5682s codec in machine driver
Add set_bais_level function for rt5682s codec to enable bclk and lrclk
before codec widgets power on and disable bclk and lrclk after widgets
power down, to avoid pop noise
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.
Aidan MacDonald [Wed, 19 Oct 2022 01:23:02 +0000 (02:23 +0100)]
ASoC: simple-card: Fix up checks for HW param fixups
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.
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.
ASoC: soc-dapm.h: fixup comment for snd_soc_dapm_widget_for_each_path()
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.
soc-dapm.h defines many things, but it is using
randam white space and tag.
This patch do nothing, but cleanup its white space.
This patch cleanup also 100 char in 1 line.
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.
ASoC: soc-dapm.c: merge dapm_power_one_widget() and dapm_widget_set_power()
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.
ASoC: soc-dapm.c: ignore parameter NULL at snd_soc_dapm_free_widget()
Currently snd_soc_dapm_free_widget() is assuming input parameter is
non NULL. Thus, caller need to care about it.
This patch care it at snd_soc_dapm_free_widget().
ASoC: soc-dapm.c: remove no meaning variable from snd_soc_dapm_add_path()
snd_soc_dapm_add_path() is using local variable "widgets[]", but it is
same as path->node[].
This is no meaning and duplicate operation. This patch removes "widgets[]".
ASoC: soc-dapm.c: tidyup error handling on snd_soc_dapm_add_route()
Current error handling on snd_soc_dapm_add_route() has some wastes.
It indicates *own* error message *only* for sink or source,
and return error directly at (A). OTOH, it has similar error message at
(B) which indicates *both* sink/source.
And more, (A) is using dev_err(), (B) is using dev_warn().
(B) is caring prefix, but (A) is not.
(X) int snd_soc_dapm_add_route(...)
{
...
if (wsource == NULL) {
(A) dev_err(...);
return -ENODEV;
}
if (wsink == NULL) {
(A) dev_err(...);
return -ENODEV;
}
...
ret = snd_soc_dapm_add_path(...);
if (ret)
(B) goto err;
return 0;
err:
(B) dev_warn(...);
return ret;
}
Above snd_soc_dapm_add_route() (= X) is called from
snd_soc_dapm_add_routes() (= Y).
(X) will indicate error message by itself, but (Y) will indicate
own error message at (C). (C) is duplicated.
(Y) int snd_soc_dapm_add_routes(...)
{
...
for (...) {
(X) int r = snd_soc_dapm_add_route(...);
if (r < 0) {
(C) dev_err(...);
ret = r;
}
...
}
...
}
This patch (1) merges these error message (= A,B) into one,
(2) use dev_err(), (3) remove duplicate error message (= C) from
snd_soc_dapm_add_routes().
By this patch, it will indicate error message like this.
- error message with prefix
- not found widget will have "(*)" mark
- it indicates [control] if exists.
ex)
[if no sink with control]
ASoC: Failed to add route SOURCE -> [CTRL] -> SINK(*)
All Intel drivers for cAVS platforms contain a sequence for S3 resume
which doesn't seem justified nor necessary. Forensic Git investigation
in internal repositories did not provide any rationale for the
implementation, and tests show no impact when those sequences are
removed.
This sequence was identified as problematic during a large HDaudio
cleanup where all programming sequences were revisited before
extensions are added.
Kai Vehmanen [Tue, 18 Oct 2022 12:13:32 +0000 (15:13 +0300)]
ASoC: SOF: ipc4-mtrace: protect per-core nodes against multiple open
Add protection against multiple open of the mtrace/coreN debugfs
nodes. This is not supported in the implementation, and this will
show up as unexpected behaviour of the interface, and potential
use of already freed memory.
Peter Ujfalusi [Tue, 18 Oct 2022 12:40:08 +0000 (15:40 +0300)]
ASoC: SOF: Intel: ipc4: Ack a received reply or notification separately
By acking a received message we tell the DSP that we have processed the
message (reply or notification) and we are open to receive a new one.
The original implementation did this in a common code after the received
message got handled as reply or notification.
With right timing this opens up a small window when we have processed the
reply and let the other thread proceed to send a new message to the DSP,
which is allowed as the DSP is free to receive message.
But when the message is received and processed by the DSP and it wants to
send a reply it will still see that the previous message has not been
acked, so it fails to send a reply. Later the first reply got acked by the
kernel, but it is too late and the in-flight message got a timeout due to
firmware not responding (which it tried, but could not).
Peter Ujfalusi [Tue, 18 Oct 2022 12:40:07 +0000 (15:40 +0300)]
ASoC: SOF: Intel: ipc4: Wait for channel to be free before sending a message
Before attempting to send a message to the DSP we need to check if the
downstream BUSY flag has been cleared by the firmware to avoid lost IPC
messages by the firmware.
This is required by a firmware which only acks the received message after
it has sent a reply to the host.
With a bad luck, the host would send a message before the firmware gets to
the clearing the flag and thus losing a message.
ASoC: soc-dapm.c: ignore parameter NULL at snd_soc_dapm_free_widget()
Currently snd_soc_dapm_free_widget() is assuming input parameter is
non NULL. Thus, caller need to care about it.
This patch care it at snd_soc_dapm_free_widget().
ASoC: soc-dapm.c: remove no meaning variable from snd_soc_dapm_add_path()
snd_soc_dapm_add_path() is using local variable "widgets[]", but it is
same as path->node[].
This is no meaning and duplicate operation. This patch removes "widgets[]".
ASoC: soc-dapm.c: tidyup error handling on snd_soc_dapm_add_route()
Current error handling on snd_soc_dapm_add_route() has some wastes.
It indicates *own* error message *only* for sink or source,
and return error directly at (A). OTOH, it has similar error message at
(B) which indicates *both* sink/source.
And more, (A) is using dev_err(), (B) is using dev_warn().
(B) is caring prefix, but (A) is not.
(X) int snd_soc_dapm_add_route(...)
{
...
if (wsource == NULL) {
(A) dev_err(...);
return -ENODEV;
}
if (wsink == NULL) {
(A) dev_err(...);
return -ENODEV;
}
...
ret = snd_soc_dapm_add_path(...);
if (ret)
(B) goto err;
return 0;
err:
(B) dev_warn(...);
return ret;
}
Above snd_soc_dapm_add_route() (= X) is called from
snd_soc_dapm_add_routes() (= Y).
(X) will indicate error message by itself, but (Y) will indicate
own error message at (C). (C) is duplicated.
(Y) int snd_soc_dapm_add_routes(...)
{
...
for (...) {
(X) int r = snd_soc_dapm_add_route(...);
if (r < 0) {
(C) dev_err(...);
ret = r;
}
...
}
...
}
This patch (1) merges these error message (= A,B) into one,
(2) use dev_err(), (3) remove duplicate error message (= C) from
snd_soc_dapm_add_routes().
By this patch, it will indicate error message like this.
- error message with prefix
- not found widget will have "(*)" mark
- it indicates [control] if exists.
ex)
[if no sink with control]
ASoC: Failed to add route SOURCE -> [CTRL] -> SINK(*)
The flow contains surprising parts that seem to have been inspired by
the Skylake driver.
During a resume from S3, the state of the links prior to suspend
should not matter. One would have to assume that the links are powered
down anyways prior to suspend, and there is also no specific code that
turns links on unconditionally on resume.
Likewise, the snd_hdac_init_chip() routine will start the cmd_io
handling, and it's not clear why we should care about the state of the
DMA prior to suspend.
This patch removes these two sequences to simplify the flow.
Commit cce6c149eba3a ("ASoC: Intel: Skylake: add link management")
added a perfectly logical/symmetrical link handling for
'suspend_active' aka S0ix
However that commit also added a less obvious part, where during S3
resume the code will "turn off the links which are off before suspend"
as well as stop the cmd_io which is not started.
This sequence looks completely unnecessary and possibly wrong, remove it.
Initial IPC4 tests used the same conventions as previous reference
closed-source firmware, but for MeteorLake the convention is the same
as previous SOF releases (sof-<platform>.ri). Only the prefix changes
to avoid confusions between IPC types.
This change has no impact on users since the firmware has not yet been
released.
This series adds devicetree support for the Wolfson WM8961 codec. The
first patch adds a schema, the second patch hooks it up in the code, and
the third patch allows it to be selected in Kconfig.
Two fixes are leading the way - one addresses the incorrect DMA mask
assignment (typo) at driver probe. The other, fixes a potential buffer
overflow when copying data received from firmware to kernel buffer.
However unlikely, the fix should still be there.
Then a range of patches providing the support for:
- AML with rt286 (machine board)
- KBL-R for rt298 (codec)
- KBL-R with rt298 (machine board)
- APL/KBL with da7219 (machine board)
- Addition of all the missing SKL-based PCI ids to core.c
Of the remaining changes, only one stands out - special case is provided
for "unsupported" IPCs. The driver supports a range of platforms,
however, on some generations given IPC may not be supported. Such call
shall not be treated as "invalid" - those are two different scenarios.
Everything else in the patchset is mostly a readability improvement:
spelling fixes and log messages issues, code simplification.
At a previous time, we have successfully created a virtual sound card
based on rpmsg. The sound card works under this mechanism Cortex-A core
tells the Cortex-M core the format, rate, channel, .etc configuration
of the PCM parameters and Cortex-M controls real hardware devices such
as SAI and DMA. From the view of Linux side, the sound card is bound to
a rpmsg channel through which it can access SAI.
Here these patches are introduced to create a new virtual sound card to
access MICFIL based on a new created rpmsg channel. It's easy to create
a new rpmsg channel for MICFIL through rpmsg name service announcment.
Also the other ASoC components bound to this rpmsg MICFIL sound card
will be registered with these patches.
If other sound cards using different hardware devices needs to be
created over rpmsg in the future, these patches can be referred.
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
The patchset improves:
- Exposes output stage (post mixer) gain control and makes it new
Master playback gain, DAC gain was the previous master.
However, no Master mute now.
- Exposes all mixer inputs (both Mics, LineIn and DAC) with their
gain controls.
- Exposes microphones widgets: single/differential input, boost.
Known issues:
- Bypass path enablement isn't applied immediately, for make
things going bit clock needs to be triggered for a bit,
e.g. by aplay dummy.wav
It might be a hardware bug, since the bit clock isn't
declared as required for codec operation.
Tested on:
- Ritmix RZX-27 (jz4725b).
- Ritmix RZX-50 (jz4755).
Randy Dunlap [Sat, 15 Oct 2022 00:12:28 +0000 (17:12 -0700)]
ASoC: qcom: SND_SOC_SC7180 optionally depends on SOUNDWIRE
If SOUNDWIRE is enabled, then SND_SOC_SC7180 should depend on
SOUNDWIRE to prevent SOUNDWIRE=m and SND_SOC_SC7180=y, which causes
build errors:
s390-linux-ld: sound/soc/qcom/common.o: in function `qcom_snd_sdw_prepare':
common.c:(.text+0x140): undefined reference to `sdw_disable_stream'
s390-linux-ld: common.c:(.text+0x14a): undefined reference to `sdw_deprepare_stream'
s390-linux-ld: common.c:(.text+0x158): undefined reference to `sdw_prepare_stream'
s390-linux-ld: common.c:(.text+0x16a): undefined reference to `sdw_enable_stream'
s390-linux-ld: common.c:(.text+0x17c): undefined reference to `sdw_deprepare_stream'
s390-linux-ld: sound/soc/qcom/common.o: in function `qcom_snd_sdw_hw_free':
common.c:(.text+0x344): undefined reference to `sdw_disable_stream'
s390-linux-ld: common.c:(.text+0x34e): undefined reference to `sdw_deprepare_stream'
ASoC: codecs: tlv320adc3xxx: Wrap adc3xxx_i2c_remove() in __exit_p()
If CONFIG_SND_SOC_TLV320ADC3XXX=y:
`.exit.text' referenced in section `.data' of sound/soc/codecs/tlv320adc3xxx.o: defined in discarded section `.exit.text' of sound/soc/codecs/tlv320adc3xxx.o
Fix this by wrapping the adc3xxx_i2c_remove() pointer in __exit_p().
Siarhei Volkau [Sun, 16 Oct 2022 13:26:47 +0000 (16:26 +0300)]
ASoC: codecs: jz4725b: add missed Mixer inputs
The Mixer couples analog input from 4 sources (DAC, Line In, Mic 1,
Mic 2) each input has its own gain & mute controls.
At the moment only DAC is implemented fully and Line In path can be
switched on/off. The patch implements Mic 1 and Mic 2 paths and fully
implements Line In path.
Manual states that these controls (16.6.3.3 Programmable attenuation:
GOi) gain varies from -22.5dB to +6.0dB with 1.5dB step. Also there's
extra values below the minimum, but they behave the same as the minimum
value.
Siarhei Volkau [Sun, 16 Oct 2022 13:26:46 +0000 (16:26 +0300)]
ASoC: codecs: jz4725b: use right control for Master Playback
At the moment DAC control is used as Master Playback control, this is
incorrect as DAC's output goes to a Mixer.
The Mixer couples analog input from 4 sources (DAC, Line In, Mic 1,
Mic 2) each input has its own gain & mute controls.
Output of the Mixer goes to Output Stage control which is the best suite
for the new Playback Master. However, it doesn't have mute capability.
The patch implements Output Stage control as a new master and renames
old Master to DAC. Rest of mixer inputs will be implemented in the next
patch in the series.
Manual states that Output stage control (16.6.3.5 Programmable output
amplifier: PGAT) gain varies from -33.5dB to +4.5dB, gain step isn't
fixed and has 3 opts.
Siarhei Volkau [Sun, 16 Oct 2022 13:26:44 +0000 (16:26 +0300)]
ASoC: codecs: jz4725b: use right control for Capture Volume
Line In Bypass control is used as Master Capture at the moment
this is completely incorrect.
Current control routed to Mixer instead of ADC, thus can't affect
Capture path. ADC control shall be used instead.
ADC volume control parameters are different, so the patch fixes that
as well. Manual says (16.6.3.2 Programmable input attenuation amplifier:
PGATM) that gain varies in range 0dB..22.5dB with 1.5dB step.
Siarhei Volkau [Sun, 16 Oct 2022 13:26:43 +0000 (16:26 +0300)]
ASoC: codecs: jz4725b: fix reported volume for Master ctl
DAC volume control is the Master Playback Volume at the moment
and it reports wrong levels in alsamixer and other alsa apps.
The patch fixes that, as stated in manual on the jz4725b SoC
(16.6.3.4 Programmable attenuation: GOD) the ctl range varies
from -22.5dB to 0dB with 1.5dB step.
projects / linux.git / log