Merge series from Vincenzo Frascino <vincenzo.frascino@arm.com>:
This series converts the folling Xilinx device tree binding documentation:
- xlnx,i2s
- xlnx,audio-formatter
- xlnx,spdif
to json-schema.
Note: These bindings are required for future work on the ARM Morello
Platforms device tree.
Merge series from "Nícolas F. R. A. Prado" <nfraprado@collabora.com>:
This series enables the dual digital microphones present on the Genio
700 and 510 EVK boards.
Merge series from Cezary Rojewski <cezary.rojewski@intel.com>:
Note: the patchset DOES provide functional changes to the ASoC
framework.
Current kcontrols loaded with ASoC topology allow for mono or stereo
configuration only. To expand this and provide support to up to 8
channels, first address the limitations found within the ASoC core and
then update the user (avs-driver) so that it can utilize these new
functionality. The 8 channels max stems from SND_SOC_TPLG_MAX_CHAN
constant which is part of UAPI - asoc.h.
For the ASoC side, two changes are made:
- drop the ambiguous usage of ops.info when determining the kcontrol
type
- save the num_channels value which is already part of the ALSA-topology
but is currently skipped by ASoC core when loading mixer controls
For the avs-driver side, merge PEAKVOL IPCs as there is basically no
difference between the handles and then do the same with the control
operations. The merge for the latter is done is two steps: first provide
new implementation which honors the multi-channel controls and then move
to it while dropping the now-duplicated code.
Amadeusz Sławiński (2):
ASoC: Intel: avs: Add volume control for GAIN module
ASoC: Intel: avs: Add support for mute for PEAKVOL and GAIN
Cezary Rojewski (8):
ASoC: topology: Create kcontrols based on their type
ASoC: topology: Save num_channels value for mixer controls
ASoC: Intel: avs: Make PEAKVOL configurable from topology
ASoC: Intel: avs: Update VOLUME and add MUTE IPCs
ASoC: Intel: avs: New volume control operations
ASoC: Intel: avs: Move to the new control operations
ASoC: Intel: avs: Honor the invert flag for mixer controls
ASoC: Intel: avs: Support multi-channel PEAKVOL instantiation
include/sound/soc.h | 1 +
include/uapi/sound/intel/avs/tokens.h | 4 +
sound/soc/intel/avs/control.c | 180 ++++++++++++++++++++------
sound/soc/intel/avs/control.h | 12 +-
sound/soc/intel/avs/messages.c | 111 +++++++++++++++-
sound/soc/intel/avs/messages.h | 24 +++-
sound/soc/intel/avs/path.c | 108 ++++++++++++++--
sound/soc/intel/avs/path.h | 5 +
sound/soc/intel/avs/topology.c | 47 ++++++-
sound/soc/intel/avs/topology.h | 5 +
sound/soc/soc-topology.c | 55 +++-----
11 files changed, 440 insertions(+), 112 deletions(-)
--
2.25.1
Merge series from Shengjiu Wang <shengjiu.wang@nxp.com>:
Be similar to audio graph card, support playback or capture only for
imx-audio-card.
imx-card can't directly refer to audio-graph-port.yaml, because it is
not based on 'ports'. Add playback-only and capture-only property
directly
The DMIC_GAINx_CUR registers contain the current (as in present) gain of
each DMIC. During capture, this gain will ramp up until a target value
is reached, and therefore the register is volatile since it is updated
automatically by hardware.
However, after capture the register's value returns to the value that
was written to it. So reading these registers returns the current gain,
and writing configures the initial gain for every capture.
>From an audio configuration perspective, reading the instantaneous gain
is not really useful. Instead, reading back the initial gain that was
configured is the desired behavior. For that reason, consider the
DMIC_GAINx_CUR registers as non-volatile, so the regmap's cache can be
used to retrieve the values, rather than requiring pm runtime resuming
the device.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20250225-genio700-dmic-v2-3-3076f5b50ef7@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The PEAKVOL module initialization procedure allows for specifying
default configuration for all individual channels. To reflect that in
the code, first update avs_get_module_control() to allow for selecting
Volume or Mute control based on needs and then apply the settings with
newly added avs_peakvol_set_volume() and avs_peakvol_set_mute().
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20250217102115.3539427-11-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
To provide multi-channel - more than 2 - capability to volume controls
implement operations that honor the num_channels of a mixer control. As
mc->num_channels can be 0 and is in fact the default behavior, the new
functions decide between ALL_CHANNELS_MASK and individual channels based
on the field value.
To avoid hard-to-review delta when refactoring the code, first implement
the new behavior with follow up changes cleaning things up.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20250217102115.3539427-7-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
For mute kcontrols to have an effect add IPCs for triggering the mute
operation on the DSP side. On top of basic get/set, an aggregated
variant of the latter is provided for both MUTE and, to already present
VOLUME IPC. It allows for efficient transmission of multiple parameters
at once.
While at it, sort the functions - getters come before setters in the
AudioDSP firmware interface as well as in the kcontrol one.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20250217102115.3539427-6-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver exposes volume kcontrols if PEAKVOL/GAIN module is present
in the streaming path. Currently there is no control over their default
values including the effect that may accompany the volume change event.
Add template for PEAKVOL/GAIN module which holds all the information
needed to address the limitation.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20250217102115.3539427-4-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fields ->ops.info and ->type of struct snd_soc_tplg_ctl_hdr denote
info-operation type and control type respectively. These are two
different pieces of information. The info type is represented by
SND_SOC_TPLG_CTL_xxx and SND_SOC_TPLG_DAPM_CTL_xxx on UAPI side whereas
for control type it is SND_SOC_TPLG_TYPE_xxx (mixer, bytes or enum).
The type of the kcontrol to be created is currently guessed based on the
value of the ->ops.info. Use the ->type instead to correct and simplify
the code. With this change ops.info() can be customized by sound drivers
utilizing the ASoC-topology just like ops.get() and ops.put() can be.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20250217102115.3539427-2-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Mario Limonciello <superm1@kernel.org>:
The various AMD audio drivers have self contained implementations
for SMN router communication that require hardcoding the bridge ID.
These implementations also don't prevent race conditions with other
drivers performing SMN communication.
A new centralized driver AMD_NODE is introduced and all drivers in
the kernel should use this instead. Adjust all AMD audio drivers to
use it.
