Merge series from Charles Keepax <ckeepax@opensource.cirrus.com>:
This series is the next step of adding SDCA support. Here we add
helper functions to allow drivers to easily use the SDCA DisCo
information to create a register map for the device.
The basic idea here is the code takes the list of SDCA controls parsed
from DisCo and uses primarily the Access Mode to determine if the
register should be marked as readable/writable etc. Further more
some additional concepts such as DisCo Constants and Defaults are
handled. There is some potential confusion, as DisCo Constants are
handled as an entry in the regmap defaults table, whereas a DisCo
Default is simply handled as a write to the register. Alas the naming
confusion is an unavoidable result of the slight impedance mismatch
between the two systems.
The 'msk' variable has no initialization:
sound/soc/mediatek/mt8188/mt8188-dai-dmic.c:311:4: error: variable 'msk' is uninitialized when used here [-Werror,-Wuninitialized]
311 | msk |= PWR2_TOP_CON1_DMIC_FIFO_SOFT_RST_EN(i);
| ^~~
Set it to zero before the loop.
Fixes: c1e42ec041 ("ASoC: mediatek: mt8188: Add support for DMIC")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Link: https://patch.msgid.link/20250227131939.1040168-1-arnd@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The concept of an SDCA default value differs slightly from the regmap
usage of the term. An SDCA default is a value that is parsed from DisCo
and then written out to the hardware if no user value has superceded
it. Add a helper function that will iterate through all the SDCA
Controls and write out any default values. After these have been written
out once they will exist in the cache and that will take care of any
user values superceeding them. The code here also writes out any
Controls with a fixed value as there is only one available value for
these Controls there is no point in allowing the user to select them,
simply treat them similarly to a default.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250217140159.2288784-5-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add helper functions that SDCA drivers can use to calculate the
properties of SDCA Controls (registers) specified through DisCo.
Most of these are fairly obvious from the SDCA Access Modes.
DisCo Constants, values which are specified in the ACPI rather than on
the device, are handled as unreadable and unwritable registers. The
intention is these will be populated in the register defaults table
allowing drivers to read them normally. This means the drivers can be
agnostic as to which values are DisCo Constants.
Finally, support for SDCA Dual Ranked Controls is currently limited
here, at the moment the current value will be used directly. Writing
the current value directly is valid as per the specification
although the synchronicity of updates across multiple registers is
lost. Support for this will probably need to be added later. But its a
fairly hard problem and doesn't need to be solved immediately.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250217140159.2288784-3-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
