Charles Keepax [Wed, 12 Mar 2025 17:22:04 +0000 (17:22 +0000)]
ASoC: SDCA: Add SDCA Control Range data access helper
SDCA Ranges are two dimensional arrays of data associated with controls,
add a helper to provide an x,y access mechanism to the data and a helper
to locate a specific value inside a range.
Charles Keepax [Wed, 12 Mar 2025 17:22:03 +0000 (17:22 +0000)]
ASoC: SDCA: Add type flag for Controls
SDCA Controls come in a variety of data formats, to simplify later
parsing work out this data type as the control is parsed and stash it
for later use.
Charles Keepax [Wed, 12 Mar 2025 17:22:02 +0000 (17:22 +0000)]
ASoC: SDCA: Allow naming of imp def controls
Implementation defined controls will not be present in the large list of
known controls for SDCA. The driver should not return an error for these,
because it is perfectly legal to have implementation defined controls.
Update the handling to instead generate a generic name.
Charles Keepax [Wed, 12 Mar 2025 17:22:00 +0000 (17:22 +0000)]
ASoC: SDCA: Tidy up initialization write parsing
Slightly neaten up the initialization write code to overlay a struct
rather than shifting the pointer along manually. This also removes the
Sparse warning:
sound/soc/sdca/sdca_functions.c:233:36: warning: cast to restricted __le32
Mark Brown [Fri, 14 Mar 2025 03:11:27 +0000 (03:11 +0000)]
ASoC: sun4i-codec: add headphone dectection for
Merge series from Ryan Walklin <ryan@testtoast.com>:
Hi All,
V3 of this patch adding headphone jack detection support to the Anbernic RGnnXX series of handhelds. V3 corrects my misunderstanding of derivation of ALSA UCM file paths, and adds recieved Reviewed-by and Tested-by tags. Thanks to those that have reviewed and fed back on previous versions.
Original message below:
This series adds the required device tree bindings to describe GPIOs for jack detection in the sun4i-codec driver, adds support for jack detection to the codec machine driver, and describes the hardware configuration in the RG35XX DTS. The existing speaker amplifier GPIO pin can then be used in concert with jack detection to enable userspace sound servers (via an ALSA UCM configuration) to disable the speaker route when headphones are connected.
Thanks to Chris Morgan for his assistance putting this series together.
Regards,
Ryan
Chris Morgan (2):
ASoC: dt-bindings: sun4i-a10-codec: add hp-det-gpios
arm64: dts: allwinner: h700: Add hp-det-gpios for Anbernic RG35XX
Ryan Walklin (3):
ASoC: sun4i-codec: correct dapm widgets and controls for h616
ASoC: sun4i-codec: support hp-det-gpios property
ASoC: sun4i-codec: add h616 card long_name
Ryan Walklin [Fri, 14 Feb 2025 22:02:27 +0000 (11:02 +1300)]
ASoC: sun4i-codec: add h616 card long_name
Adding jack detection requires sound servers to act on the emitted
events, which are described by ALSA Use Case Manager configurations in
userspace. These configurations include the long card name in the file
path (falling back to card->name if this is not present), so add a long
card name for the H616 without spaces, making UCM referencing easier.
The corresponding ALSA UCM patch is here (now merged):
https://github.com/alsa-project/alsa-ucm-conf/pull/491
Signed-off-by: Ryan Walklin <ryan@testtoast.com>
--
Changelog v1..v2:
- Separate patch for card->long_name
- Note UCM patch link
Changelog v2..v3:
- Add card->long_name rather than change existing card->name
Ryan Walklin [Fri, 14 Feb 2025 22:02:25 +0000 (11:02 +1300)]
ASoC: sun4i-codec: support hp-det-gpios property
Add support for GPIO headphone detection with the hp-det-gpios
property. In order for this to properly disable the path upon
removal of headphones, the output must be labelled Headphone which
is a common sink in the driver.
Describe a headphone jack and detection GPIO in the driver, check for
a corresponding device tree node, and enable jack detection in a new
machine init function if described.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Signed-off-by: Ryan Walklin <ryan@testtoast.com>
--
Changelog v1..v2:
- Separate DAPM changes into separate patch and add rationale.
Ryan Walklin [Fri, 14 Feb 2025 22:02:24 +0000 (11:02 +1300)]
ASoC: sun4i-codec: correct dapm widgets and controls for h616
The previous H616 support patch added a single LINEOUT DAPM pin switch
to the card controls. As the codec in this SoC only has a single route,
this seemed reasonable at the time, however is redundant given the
existing DAPM codec widget definitions controlling the digital and
analog sides of the codec.
It is also insufficient to describe the scenario where separate
components (muxes, jack detection etc) are used to modify the audio
route external to the SoC. For example the Anbernic RG(##)XX series of
devices uses a headphone jack detection switch, GPIO-controlled speaker
amplifier and a passive external mux chip to route audio.
Remove the redundant LINEOUT card control, and add a Speaker pin switch
control and Headphone DAPM widget to allow control of the above
hardware.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Signed-off-by: Ryan Walklin <ryan@testtoast.com> Tested-by: Philippe Simons <simons.philippe@gmail.com> Link: https://patch.msgid.link/20250214220247.10810-3-ryan@testtoast.com Signed-off-by: Mark Brown <broonie@kernel.org>
Devices integrating Allwinner SoCs may use line-out or headphone jacks
with jack detection circuits attached to a GPIO. Support defining these
in DTs.
A number of Anbernic devices featuring the H700 SoC use this mechanism
to switch between a headphone jack and an internal speaker, so add these
to the allowed routing items.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Signed-off-by: Ryan Walklin <ryan@testtoast.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
--
Changelog v1..v2:
- Remove vendor prefix from hp-det-gpios
Martin Povišer [Thu, 27 Feb 2025 12:07:33 +0000 (22:07 +1000)]
ASoC: tas2770: Fix and redo I/V sense TDM slot setting logic
The former code sets the V slot from inside set_bitwidth according to
the bitwidth of the PCM format. That's wrong, since:
* It overrides the V slot parsed from DT binding.
* The V slot is set shifted behind the I slot by the length of the PCM
bitwidth, but the PCM bitwidth has no assured relation to the TDM
slot width.
Replace the former logic by setting up the I/V sense transmission only
in case of both I/V slots being specified in devicetree, and never
override those values. In case the slots are left unspecified, disable
the transmission completely.
There's an improbable case someone is relying on the old behavior, but
if so, that's a setup that only works by accident, and cannot be sanely
supported going forward. There's no indication anyone is consuming the
I/V sense data up to today, so break the former behavior.
Martin Povišer [Thu, 27 Feb 2025 12:07:30 +0000 (22:07 +1000)]
ASoC: tas2764: Extend driver to SN012776
SN012776 is a speaker amp chip found in Apple's 2021 laptops. It appears
similar and more-or-less compatible to TAS2764. Extend the TAS2764
driver with some SN012776 specifics and configure the chip assuming
it's in one of the Apple machines.
James Calligeros [Thu, 27 Feb 2025 12:07:28 +0000 (22:07 +1000)]
ASoC: dt-bindings: tas27xx: add compatible for SN012776
The TI SN012776 is a variant of TAS2764 found in Apple Silicon Macs.
It continues Apple's long-standing policy of getting vendors to
spin out subtly incompatible and Apple-exclusive variants of their
publicly available parts.
ASoC: simple-card-utils: Don't use __free(device_node) at graph_util_parse_dai()
commit 419d1918105e ("ASoC: simple-card-utils: use __free(device_node) for
device node") uses __free(device_node) for dlc->of_node, but we need to
keep it while driver is in use.
Don't use __free(device_node) in graph_util_parse_dai().
Fixes: 419d1918105e ("ASoC: simple-card-utils: use __free(device_node) for device node") Reported-by: Thuan Nguyen <thuan.nguyen-hong@banvien.com.vn> Reported-by: Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by: Thuan Nguyen <thuan.nguyen-hong@banvien.com.vn> Tested-by: Detlev Casanova <detlev.casanova@collabora.com> Link: https://patch.msgid.link/87eczisyhh.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
Arnd Bergmann [Wed, 5 Mar 2025 17:27:32 +0000 (18:27 +0100)]
ASoC: cs42l43: convert to SYSTEM_SLEEP_PM_OPS
The custom suspend function causes a build warning when CONFIG_PM_SLEEP
is disabled:
sound/soc/codecs/cs42l43.c:2405:12: error: unused function 'cs42l43_codec_runtime_force_suspend' [-Werror,-Wunused-function]
Change SET_SYSTEM_SLEEP_PM_OPS() to the newer SYSTEM_SLEEP_PM_OPS(),
to avoid this.
Fixes: 164b7dd4546b ("ASoC: cs42l43: Add jack delay debounce after suspend") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Maciej Strozek <mstrozek@opensource.cirrus.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250305172738.3437513-1-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
Move acp_dev_data structure members to acp_chip_info structure
to avoid using common members in each structure and remove redundant
acp_dev_data structure.
ASoC: cs35l41: check the return value from spi_setup()
Currently the return value from spi_setup() is not checked for a failure.
It is unlikely it will ever fail in this particular case but it is still
better to add this check for the sake of completeness and correctness. This
is cheap since it is performed once when the device is being probed.
Handle spi_setup() return value.
Found by Linux Verification Center (linuxtesting.org) with Svace.
Bard Liao [Mon, 10 Mar 2025 08:04:40 +0000 (16:04 +0800)]
ASoC: rt722-sdca: add missing readable registers
SDW_SDCA_CTL(FUNC_NUM_MIC_ARRAY, RT722_SDCA_ENT_FU15,
RT722_SDCA_CTL_FU_CH_GAIN, CH_01) ... SDW_SDCA_CTL(FUNC_NUM_MIC_ARRAY,
RT722_SDCA_ENT_FU15, RT722_SDCA_CTL_FU_CH_GAIN, CH_04) are used by the
"FU15 Boost Volume" control, but not marked as readable.
And the mbq size are 2 for those registers.
Fixes: 7f5d6036ca005 ("ASoC: rt722-sdca: Add RT722 SDCA driver") Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Shuming Fan <shumingf@realtek.com> Link: https://patch.msgid.link/20250310080440.58797-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Mark Brown [Sun, 9 Mar 2025 13:42:54 +0000 (13:42 +0000)]
ASoC: SOF: Intel: Add support for ACE3+ mic privacy
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
ACE3 (Panther Lake) introduced support for microphone privacy feature which
can - in hardware - mute incoming audio data based on a state of a physical
switch.
The change in the privacy state is delivered through interface IP blocks
and can only be handled by the link owner.
In Intel platforms Soundwire is for example host owned, so the interrupt
can only be handled by the host.
Since the input stream is going to be muted by hardware, the host needs to
send a message to firmware about the change in privacy so it can execute a
fade out/in to enhance user experience.
The support for microphone privacy can be queried from the HW_CONFIG data
under the INTEL_MIC_PRIVACY_CAP tuple. This is Intel specific data, the
core will pass it to platform code if the intel_configure_mic_privacy()
callback is provided.
Platform code can call sof_ipc4_mic_privacy_state_change() to send the IPC
message to the firmware on state change.
Mark Brown [Sun, 9 Mar 2025 13:42:47 +0000 (13:42 +0000)]
ASoC: dmic: add regulator support
Merge series from Olivier Moysan <olivier.moysan@foss.st.com>:
Digital microphones may be supplied by a regulator. Add regulator
support in dmic codec, to allow power management of the regulator
through the ASoC DAPM widgets.
Peter Ujfalusi [Fri, 7 Mar 2025 11:28:16 +0000 (13:28 +0200)]
ASoC: SOF: Intel: ptl: Add support for mic privacy
Implement the three callbacks that is needed to enable support for
reporting the mic privacy change via soundwire.
In PTL the mic privacy reporting is supported via soundwire and DMIC and
the soundwire is owned by the host, it's interrupt is routed there.
To enable the interrupt, the sublink mask needs to be passed to the
multilink layer, the check_mic_privacy_irq/process_mic_privacy callbacks
needs to be implemented to check and report the mic privacy change.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://patch.msgid.link/20250307112816.1495-9-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Peter Ujfalusi [Fri, 7 Mar 2025 11:28:15 +0000 (13:28 +0200)]
ASoC: SOF: hda/shim: Add callbacks to handle mic privacy change for sdw
Add generic callback definitions for checking the mic privacy interrupt and
status.
Implement wrappers for mic privacy reported via the Soundwire interrupt and
its vendor specific SHIM registers.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://patch.msgid.link/20250307112816.1495-8-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Peter Ujfalusi [Fri, 7 Mar 2025 11:28:14 +0000 (13:28 +0200)]
ASoC: SOF: Intel: hda-mlink: Add support for mic privacy in VS SHIM registers
New register has been introduced with PTL in the vendor specific SHIM
registers, outside of the IPs itself for microphone privacy status handling.
Via the PVCCS register the current microphone privacy status can be checked
and the interrupt generation on status change can be enabled/disabled.
The status change interrupt is routed to the owner of the interface
(DSP/host).
The PVCCS is provided for each sublink under the IP to make it possible to
control the interrupt generation per sublink.
On status change the MDSTSCHG bit needs to be cleared for all sublink of
the interface to be able to detect future changes in privacy.
The status bit (MDSTS) is volatile in all PVCCS register, it reflects the
current state of the GPIO signal.
Microphone privacy is a hardware feature (if enabled and configured that
way), the host has only passive, monitoring role.
The added functions are generic to be future proof if the mic privacy
support is extended beyond Soundwire and DMIC links.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://patch.msgid.link/20250307112816.1495-7-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Peter Ujfalusi [Fri, 7 Mar 2025 11:28:13 +0000 (13:28 +0200)]
ASoC: SOF: ipc4: Add support for Intel HW managed mic privacy messaging
ACE3 (Panther Lake) introduced support for microphone privacy feature which
can - in hardware - mute incoming audio data based on a state of a physical
switch.
The change in the privacy state is delivered through interface IP blocks
and can only be handled by the link owner.
In Intel platforms Soundwire is for example host owned, so the interrupt
can only be handled by the host.
Since the input stream is going to be muted by hardware, the host needs to
send a message to firmware about the change in privacy so it can execute a
fade out/in to enhance user experience.
The support for microphone privacy can be queried from the HW_CONFIG data
under the INTEL_MIC_PRIVACY_CAP tuple. This is Intel specific data, the
core will pass it to platform code if the intel_configure_mic_privacy()
callback is provided.
Platform code can call sof_ipc4_mic_privacy_state_change() to send the IPC
message to the firmware on state change.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://patch.msgid.link/20250307112816.1495-6-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Peter Ujfalusi [Fri, 7 Mar 2025 11:28:10 +0000 (13:28 +0200)]
ASoC: SOF: Intel: lnl/ptl: Only set dsp_ops which differs from MTL
LunarLake is a next generation in ACE architecture and most of the dsp_ops
are the same as it is in previous generation.
Use the sof_mtl_set_ops() to get the ops used for mtl and update the ones
that needs different functions for LNL.
Update pci-ptl at the same time to use the LNL dsp_ops as before.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://patch.msgid.link/20250307112816.1495-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Peter Ujfalusi [Fri, 7 Mar 2025 11:28:09 +0000 (13:28 +0200)]
ASoC: SOF: Intel: mtl: Split up dsp_ops setup code
Move the sof_mtl_ops and sof_mtl_ops_init() to pci-mtl.c as local static
and add a 'generic' sof_mtl_set_ops() function as replacement exported
function to fill the dsp_ops structure.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://patch.msgid.link/20250307112816.1495-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Thomas Mizrahi [Sat, 8 Mar 2025 04:06:28 +0000 (01:06 -0300)]
ASoC: amd: yc: Support mic on another Lenovo ThinkPad E16 Gen 2 model
The internal microphone on the Lenovo ThinkPad E16 model requires a
quirk entry to work properly. This was fixed in a previous patch (linked
below), but depending on the specific variant of the model, the product
name may be "21M5" or "21M6".
The following patch fixed this issue for the 21M5 variant:
https://lore.kernel.org/all/20240725065442.9293-1-tiwai@suse.de/
This patch adds support for the microphone on the 21M6 variant.
Arnd Bergmann [Wed, 5 Mar 2025 17:27:32 +0000 (18:27 +0100)]
ASoC: cs42l43: convert to SYSTEM_SLEEP_PM_OPS
The custom suspend function causes a build warning when CONFIG_PM_SLEEP
is disabled:
sound/soc/codecs/cs42l43.c:2405:12: error: unused function 'cs42l43_codec_runtime_force_suspend' [-Werror,-Wunused-function]
Change SET_SYSTEM_SLEEP_PM_OPS() to the newer SYSTEM_SLEEP_PM_OPS(),
to avoid this.
Fixes: 164b7dd4546b ("ASoC: cs42l43: Add jack delay debounce after suspend") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250305172738.3437513-1-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
Charles Keepax [Thu, 6 Mar 2025 10:42:33 +0000 (10:42 +0000)]
ASoC: dapm: Fix changes to DECLARE_ADAU17X1_DSP_MUX_CTRL
The changes to DECLARE_ADAU17X1_DSP_MUX_CTRL did avoid the issue with a
compiler not liking all the macro indirection. However it introduced a
new issue with respect to the mux not being declared static:
sound/soc/codecs/adau17x1.c:275:8: sparse: sparse: symbol
'adau17x1_dac_mux' was not declared. Should it be static?
sound/soc/codecs/adau17x1.c:278:8: sparse: sparse: symbol
'adau17x1_capture_mux' was not declared. Should it be static?
Fix this up by going back to the inline declaration of the soc_enum, but
just call SOC_ENUM_EXT directly rather than indirecting through
SOC_DAPM_ENUM_EXT.
Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202503061119.4QGlnOi6-lkp@intel.com/ Fixes: c951b20766f0 ("ASoC: dapm: Use ASoC control macros where possible") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250306104233.1638625-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
Charles Keepax [Fri, 28 Feb 2025 15:14:56 +0000 (15:14 +0000)]
ASoC: ops: Consistently treat platform_max as control value
This reverts commit 9bdd10d57a88 ("ASoC: ops: Shift tested values in
snd_soc_put_volsw() by +min"), and makes some additional related
updates.
There are two ways the platform_max could be interpreted; the maximum
register value, or the maximum value the control can be set to. The
patch moved from treating the value as a control value to a register
one. When the patch was applied it was technically correct as
snd_soc_limit_volume() also used the register interpretation. However,
even then most of the other usages treated platform_max as a
control value, and snd_soc_limit_volume() has since been updated to
also do so in commit fb9ad24485087 ("ASoC: ops: add correct range
check for limiting volume"). That patch however, missed updating
snd_soc_put_volsw() back to the control interpretation, and fixing
snd_soc_info_volsw_range(). The control interpretation makes more
sense as limiting is typically done from the machine driver, so it is
appropriate to use the customer facing representation rather than the
internal codec representation. Update all the code to consistently use
this interpretation of platform_max.
Finally, also add some comments to the soc_mixer_control struct to
hopefully avoid further patches switching between the two approaches.
Bard Liao [Wed, 5 Mar 2025 13:41:13 +0000 (21:41 +0800)]
ASoC: rt1320: set wake_capable = 0 explicitly
"generic_new_peripheral_assigned: invalid dev_num 1, wake supported 1"
is reported by our internal CI test.
Rt1320's wake feature is not used in Linux and that's why it is not in
the wake_capable_list[] list in intel_auxdevice.c.
However, BIOS may set it as wake-capable. Overwrite wake_capable to 0
in the codec driver to align with wake_capable_list[].
Signed-off-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> Acked-by: Shuming Fan <shumingf@realtek.com> Link: https://patch.msgid.link/20250305134113.201326-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Charles Keepax [Tue, 4 Mar 2025 14:05:00 +0000 (14:05 +0000)]
ASoC: Tidy up SOC_DOUBLE_* and SOC_SINGLE_* helpers
Re-implement SOC_DOUBLE_VALUE() in terms of SOC_DOUBLE_S_VALUE().
SOC_DOUBLE_S_VALUE() already had a minimum value so add this to
SOC_DOUBLE_VALUE as well, this allows replacement of several hard coded
value entries. Likewise update SOC_SINGLE_VALUE to match, which allows
replacement of even more hard coded values.
Mark Brown [Tue, 4 Mar 2025 15:47:02 +0000 (15:47 +0000)]
Tidy up ASoC VALUE control macros
Merge series from Charles Keepax <ckeepax@opensource.cirrus.com>:
Tidy up the ASoC control value macros. Fix some drivers that should be
using core macros that aren't, combine the existing core macros to be
a little more consistent in style, and update the core macros to use
each other where possible.
Mark Brown [Tue, 4 Mar 2025 14:43:55 +0000 (14:43 +0000)]
ASoC: codecs: Update device_id tables for Realtek
Merge series from Cezary Rojewski <cezary.rojewski@intel.com>:
The series aims to streamline the formatting for ACPI IDs so that a
single pattern can be used to identify the device.
Work implicitly suggested by Andy Shevchenko - reading and learning from
number of his reviews on the Linux mailing lists.
Several formats do exists, however, after technical discussion PCI-based
format has been selected as the recommended one. For Realtek devices, it
is going to be 10ECxxxx where 10EC unambiguously identifies Realtek
company whereas the following 4 hexes specify the PART_ID i.e.: the
device.
While at it, there shall be no comma after the terminator entry and
initializing fields with 0 for statically defined structs is redundant.
Mark Brown [Tue, 4 Mar 2025 14:43:46 +0000 (14:43 +0000)]
ASoC: audio-graph-card2-custom-sample: Separate Sample
Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>:
audio-graph-card2-custom-sample has many sample connections, but because
ALSA card has number limition for links, it is impossible to have all
samples into 1 ASoC card.
This patch-set separate sample DT into 2 parts, and remove original sample.
Because of this separation, we can see all sample connection via multi Card.
Maciej Strozek [Tue, 4 Mar 2025 14:05:04 +0000 (14:05 +0000)]
ASoC: cs42l43: Add jack delay debounce after suspend
Hardware reports jack absent after reset/suspension regardless of jack
state, so introduce an additional delay only in suspension case to allow
proper detection to take place after a short delay.
Linus Walleij [Mon, 3 Mar 2025 08:41:44 +0000 (09:41 +0100)]
ASoC: samsung: speyside: Convert to GPIO descriptor
The Speyside ASoC uses a single GPIO from the WM8996
that we can provide from the local offset on that chip
rather than from the global GPIO numberspace as is being
done currently.
The offset 2 was done by calculating the base offset
for the CODEC (i.e. wm8996) GPIOs to 212, by reading
arch/arm/mach-s3c/gpio-samsung-s3c64xx.h and
arch/arm/mach-s3c/crag6410.h and adding up all the
offsets that were occasionally adding a +1 blank GPIO
between each GPIO provider.
ES8328 and ES8388 codecs are I2C or SPI devices, thus they are
addressable on their bus and 'reg' property should be always provided.
Requiring 'reg' is pretty close to redundant, because the I2C and SPI
controller/bus bindings require it already, but the convention is to
mention 'reg' also in the device schemas.
ASoC: dt-bindings: everest,es8328: Mark ES8388 compatible with ES8328
Based on Linux driver, the ES8388 looks fully compatible with ES8328.
One upstream DTS (ARM rk3288-rock2-square.dts) already uses ES8328
fallback, so mark the devices as compatible in the binding.
ASoC: mediatek: mt6359: Fix DT parse error due to wrong child node name
A recent dtbs_check error fix in mt6359.dtsi file changed a node name
(from "mt6359codec" to "audio-codec") without modifying the mt6539
codec code that uses it.
It leads to a probe failure after devicetree parsing returns in error:
```
[ 1.354025] mt6359-sound mt6359-sound: mt6359_platform_driver_probe() failed to parse dts
[ 1.355066] mt6359-sound mt6359-sound: probe with driver mt6359-sound failed with error -22
```
So, add the child node retrieval with the new name and if not found,
try with the older one for backward compatibility.
Fixes: 76b35f59bbe6 ("arm64: dts: mediatek: mt6359: fix dtbs_check error for audio-codec") Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://patch.msgid.link/20250228-mt6359-fix-probe-failed-v1-1-64941d387b2c@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
Charles Keepax [Mon, 3 Mar 2025 17:14:23 +0000 (17:14 +0000)]
ASoC: Tidy up SOC_DOUBLE_R_* helpers
Re-implement SOC_DOUBLE_R_VALUE() in terms of SOC_DOUBLE_R_S_VALUE().
SOC_DOUBLE_R_S_VALUE() already had a minimum value so add this to
SOC_DOUBLE_R_VALUE() as well, which makes SOC_DOUBLE_R_RANGE_VALUE()
redundant, so its usage is replaced.
Charles Keepax [Mon, 3 Mar 2025 17:14:22 +0000 (17:14 +0000)]
ASoC: dapm: Use ASoC control macros where possible
Update the DAPM kcontrol creation macros to use the ASoC macros where a
helpful version exists. One minor fixup is required in adau17x1, the
compiler doesn't like the extra level of macro indirection coupled with
the inline struct definition. Make the struct definition explicit.
projects / thirdparty / kernel / linux.git / log
