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
.../sound/allwinner,sun4i-a10-codec.yaml | 6 ++
.../sun50i-h700-anbernic-rg35xx-2024.dts | 5 +-
sound/soc/sunxi/sun4i-codec.c | 57 ++++++++++++++++++-
3 files changed, 66 insertions(+), 2 deletions(-)
--
2.48.1
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
Link: https://patch.msgid.link/20250214220247.10810-6-ryan@testtoast.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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.
Tested-by: Philippe Simons <simons.philippe@gmail.com>
Link: https://patch.msgid.link/20250214220247.10810-4-ryan@testtoast.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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
Changelog v2..v3:
- Add Reviewed-by tag
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Tested-by: Philippe Simons <simons.philippe@gmail.com>
Link: https://patch.msgid.link/20250214220247.10810-2-ryan@testtoast.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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.
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
Link: https://patch.msgid.link/20250227-apple-codec-changes-v3-6-cbb130030acf@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently the compiler (clang 19.1.7) is not happy about the size of
the stack frame in sof_ipc4_prepare_copier_module:
sound/soc/sof/ipc4-topology.c:1800:1: error: stack frame size (1288) exceeds limit (1024) in 'sof_ipc4_prepare_copier_module' [-Werror,-Wframe-larger-than]
1800 | sof_ipc4_prepare_copier_module(struct snd_sof_widget *swidget,
| ^
Work around this by allocating ref_params on stack, as it looks the biggest
variable on stack right now.
Note, this only happens when compile for 32-bit machines (x86_32 in my case).
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20250312160516.3864295-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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.
Fixes: 872fc0b6bd ("ASoC: cs35l41: Set the max SPI speed for the whole device")
Signed-off-by: Vitaliy Shevtsov <v.shevtsov@mt-integration.ru>
Link: https://patch.msgid.link/20250304115643.2748-1-v.shevtsov@mt-integration.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
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.
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.
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>
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>
