Mark Brown [Thu, 27 Feb 2025 16:44:41 +0000 (16:44 +0000)]
Add SDCA register map support
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.
Arnd Bergmann [Thu, 27 Feb 2025 13:19:01 +0000 (14:19 +0100)]
ASoC: mediatek: mt8188: avoid uninitialized variable use
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: c1e42ec04197 ("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>
Charles Keepax [Mon, 17 Feb 2025 14:01:59 +0000 (14:01 +0000)]
ASoC: SDCA: Add helper to write out defaults and fixed values
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.
Charles Keepax [Mon, 17 Feb 2025 14:01:58 +0000 (14:01 +0000)]
ASoC: SDCA: Add regmap helpers for parsing for DisCo Constant values
Add helpers to parse the DisCo Constant values from ACPI and populate an
array of reg_defaults with these. This will allow drivers to access
these ACPI specified values through the same interface as other
registers that are physically present on the device, using the regmap
cache.
Charles Keepax [Mon, 17 Feb 2025 14:01:57 +0000 (14:01 +0000)]
ASoC: SDCA: Add generic regmap SDCA helpers
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.
Charles Keepax [Mon, 17 Feb 2025 14:01:56 +0000 (14:01 +0000)]
regcache: Add support for sorting defaults arrays
The defaults array in regcache must be sorted into ascending register
address order, because binary search is used to locate values in
the array. Add a helper to sort the register defaults array which
can be useful for systems that dynamically create a defaults array
based on external information.
Baojun Xu [Wed, 26 Feb 2025 14:43:28 +0000 (22:43 +0800)]
ASoC: tas2781: Clean up for some define
Do some clean up for some define in header file.
Like change lower case in value, up case in define,
space add in recommends, change date of files and add author.
Mark Brown [Tue, 25 Feb 2025 15:23:45 +0000 (15:23 +0000)]
ASoC: Intel: avs: Mute and multi-channel controls
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
Add the DMIC backend, which connects to the DMIC DAI in the platform
driver, as well as a "AP DMIC" mic widget. On the Genio 700 EVK board
the dual DMIC on-board are wired through that DMIC DAI.
Co-developed-by: parkeryang <Parker.Yang@mediatek.com> Signed-off-by: parkeryang <Parker.Yang@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://patch.msgid.link/20250225-genio700-dmic-v2-5-3076f5b50ef7@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
parkeryang [Tue, 25 Feb 2025 14:33:50 +0000 (11:33 -0300)]
ASoC: mediatek: mt8188: Add support for DMIC
Add support for the DMIC DAIs present on the MT8188 SoC. To achieve
that, add a DAI driver for DMIC and register it during probe, and
describe the AFE routes that connect the DMIC (I004-I011) to the UL9
frontend (O002-O009).
Signed-off-by: parkeryang <Parker.Yang@mediatek.com> Co-developed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> 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-4-3076f5b50ef7@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: mediatek: mt8188: Treat DMIC_GAINx_CUR as non-volatile
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.
Since list_for_each_entry() expects the list to not be empty, the
iterator variable cannot be NULL and the unnecessary if-check can be
removed. Remove it and indent the code accordingly.
ASoC: q6dsp: q6apm: replace kzalloc() with kcalloc() in q6apm_map_memory_regions()
We are trying to get rid of all multiplications from allocation
functions to prevent integer overflows[1]. Here the multiplication is
obviously safe, but using kcalloc() is more appropriate and improves
readability. This patch has no effect on runtime behavior.
Cezary Rojewski [Mon, 17 Feb 2025 10:21:15 +0000 (11:21 +0100)]
ASoC: Intel: avs: Support multi-channel PEAKVOL instantiation
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().
ASoC: Intel: avs: Add support for mute for PEAKVOL and GAIN
With recent updates to AudioDSP firmware, mute functionality has been
added to PEAKVOL and GAIN modules. The operation occurs over IPC
similarly to how volume is configured. Wire it up to kcontrol
infrastructure present in the avs-driver.
Cezary Rojewski [Mon, 17 Feb 2025 10:21:12 +0000 (11:21 +0100)]
ASoC: Intel: avs: Move to the new control operations
Allow for multi-channel volume controls to be utilized by an application
by moving over to the new implementation. Drop all unused code in the
process.
Cezary Rojewski [Mon, 17 Feb 2025 10:21:11 +0000 (11:21 +0100)]
ASoC: Intel: avs: New volume control operations
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.
Cezary Rojewski [Mon, 17 Feb 2025 10:21:10 +0000 (11:21 +0100)]
ASoC: Intel: avs: Update VOLUME and add MUTE IPCs
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.
ASoC: Intel: avs: Add volume control for GAIN module
The AudioDSP firmware's GAIN module has same initialization payload as
PEAKVOL and user volume setting can be applied up-front. Update existing
code to account for PEAKVOL and GAIN both.
Cezary Rojewski [Mon, 17 Feb 2025 10:21:08 +0000 (11:21 +0100)]
ASoC: Intel: avs: Make PEAKVOL configurable from topology
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.
Cezary Rojewski [Mon, 17 Feb 2025 10:21:07 +0000 (11:21 +0100)]
ASoC: topology: Save num_channels value for mixer controls
To provide minimal support for multi-channel kcontrols i.e.: more than
stereo configuration, store the number of channels specified within the
SectionControlMixer. The field is part of the topology standard,
currently skipped by the ASoC core.
Cezary Rojewski [Mon, 17 Feb 2025 10:21:06 +0000 (11:21 +0100)]
ASoC: topology: Create kcontrols based on their type
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.
Shengjiu Wang [Mon, 17 Feb 2025 02:17:15 +0000 (10:17 +0800)]
ASoC: imx-card: Add playback_only or capture_only support
With the DPCM case, the backend only support capture or playback, then
the linked frontend can only support capture or playback, but frontend
can't automatically enable only capture or playback, it needs the input
from dt-binding.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Link: https://patch.msgid.link/20250217021715.284951-3-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
Shengjiu Wang [Mon, 17 Feb 2025 02:17:14 +0000 (10:17 +0800)]
ASoC: dt-bindings: imx-card: Add playback-only and capture-only property
Refer to audio graph card, add playback-only and capture-only property
for imx-audio-card.yaml for the case that only playback or capture is
supported.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20250217021715.284951-2-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: SOF: amd: Move depends on AMD_NODE to consumers
CONFIG_SND_SOC_SOF_AMD_COMMON is a hidden option that is only selected by
other options. It can't have a direct depends on AMD_NODE because select
can't pick another option automatically.
This was attempted to be fixed in commit b47834ee4485b ("ASoC: SOF: amd:
Add depends on CPU_SUP_AMD") but this just masked the issue as it was found
in another config.
Instead move the `depends on AMD_NODE` out of SND_SOC_SOF_AMD_COMMON to
all the consumers and drop `depends on CPU_SUP_AMD`.
Fixes: b47834ee4485b ("ASoC: SOF: amd: Add depends on CPU_SUP_AMD") Fixes: f120cf33d232 ("ASoC: SOF: amd: Use AMD_NODE") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202502220104.a8P6ApQN-lkp@intel.com/ Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/20250221181840.2639793-1-superm1@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
Raag Jadav [Wed, 12 Feb 2025 06:25:02 +0000 (11:55 +0530)]
err.h: move IOMEM_ERR_PTR() to err.h
Since IOMEM_ERR_PTR() macro deals with an error pointer, a better place
for it is err.h. This helps avoid dependency on io.h for the users that
don't need it.
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Raag Jadav <raag.jadav@intel.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
When SMN support was switched to the kernel wide AMD_NODE instead of
local implementation this broke compilation on the allyesconfig for
some architectures. AMD_NODE is only supported on AMD platforms, so
modify all the AMD drivers that use it to also require CPU_SUP_AMD.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/linux-next/20250220160950.2cd64bdb@canb.auug.org.au/ Fixes: f120cf33d232 ("ASoC: SOF: amd: Use AMD_NODE") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/20250220184822.916090-1-superm1@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
projects / thirdparty / kernel / linux.git / log
