bui duc phuc <phucduc.bui@gmail.com> says:
While cleaning up the SPEAr SPDIF driver probe path by removing
redundant error messages, build testing revealed several compilation
failures caused by outdated ASoC APIs.
The series first removes the redundant error messages, then updates the
driver to match the current ASoC APIs by replacing the removed
capture_dma_data field usage with the corresponding helper API, and
moving the DAI probe callback to struct snd_soc_dai_ops.
Link: https://patch.msgid.link/20260730095407.33894-1-phucduc.bui@gmail.com
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> says:
This is v3 of "ASoC: use .auto_selectable_formats", but separated into
small blocks. It is Step1, and it will be Step4 in total.
x: this patch-set
[x] Step1: ASoC: a to b
[ ] Step2: ASoC: codec: ...
[ ] Step3: ASoC: d to r
[ ] Step4: ASoC: r to x
Current ASoC supports snd_soc_daifmt_parse_format() which can specify DAI
format by "dai-format" property from DT.
But strictly speaking, it is SW settings, so doesn't match to DT's policy.
Current ASoC is supporting auto format select via
snd_soc_dai_ops :: .auto_selectable_formats.
But the user is very few today.
DT doesn't need to specify the DAI format via "dai-format", if both CPU
and Codec drivers were supporting .auto_selectable_formats. It will be
automatically selected from .auto_selectable_formats.
One note is that auto select might not find best format on some CPU/Codec
combination. So "dai-format" is necessary anyway.
Link: https://lore.kernel.org/r/8733zfj5jj.wl-kuninori.morimoto.gx@renesas.com
Link: https://lore.kernel.org/r/87pl0r20qo.wl-kuninori.morimoto.gx@renesas.com
Link: https://patch.msgid.link/87zezljgxy.wl-kuninori.morimoto.gx@renesas.com
Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> says:
This series adds sound support for the Monaco/Monza (VENTUNO-Q)
platform on the QCS8275 board, which uses a MAX98091 codec on an
LPI MI2S link.
Patch 2 (from Neil) registers the LPASS MCLK1..MCLK5 clock IDs in
q6prm-clocks.c. Without these entries the DT clock reference
"clocks = <&q6prmcc LPASS_CLK_ID_MCLK_3 ...>" that the MAX98091
node uses cannot resolve at probe, and the codec silently runs
without MCLK.
Note: this patch has been posted to the list more than once from Oct
2025 and does not appear to be actively pursued by anyone. I
am picking it up here because the rest of this series depends on
it to get sound working on QCS8275, and it makes little sense to
send the machine-driver changes without the clock IDs they rely
on.
With these patches now we have full audio working on Arduino VENTUNO-Q.
Link: https://patch.msgid.link/20260731162626.1588561-1-srinivas.kandagatla@oss.qualcomm.com
Dawid Wróbel <me@dawidwrobel.com> says:
Both drivers access enumerated controls through value.integer.value[0]
instead of value.enumerated.item[0]. The same bug was fixed in rx-macro
and va-macro in 2022 (bcfe5f76cc, 0ea5eff7c6); tx-macro and
wsa-macro were missed.
On 64-bit kernels with CONFIG_SND_CTL_DEBUG this trips the elem value
sanity check, and every read of the affected controls fails with
-EINVAL.
Reproduced and fixed on a Xiaomi Mi Pad 5 Pro (SM8250) for tx-macro.
wsa-macro is compile-tested only — that codec is not instantiated on
this hardware.
Link: https://patch.msgid.link/20260730-worktree-lpass-tx-macro-enum-fix-v2-0-6d091c736116@dawidwrobel.com
EAR SPKR PA Gain" and the four "WSA RX* Mux" controls are enumerated,
but their get and put callbacks access the value through
ucontrol->value.integer.value[0] (a long) instead of
ucontrol->value.enumerated.item[0] (an unsigned int).
This same pattern was fixed in the sibling drivers by
commit bcfe5f76cc ("ASoC: codecs: rx-macro: fix accessing array
out of bounds for enum type") and
commit 0ea5eff7c6 ("ASoC: codecs: va-macro: fix accessing array
out of bounds for enum type"), but wsa-macro was missed.
On 64-bit kernels with CONFIG_SND_CTL_DEBUG this trips the elem value
sanity check and every read of these controls fails with -EINVAL.
Fixes: 809bcbcece ("ASoC: codecs: lpass-wsa-macro: Add support to WSA Macro")
Fixes: 2c4066e5d4 ("ASoC: codecs: lpass-wsa-macro: add dapm widgets and route")
Assisted-by: Claude:claude-fable-5
Cc: stable@vger.kernel.org
Signed-off-by: Dawid Wróbel <me@dawidwrobel.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730-worktree-lpass-tx-macro-enum-fix-v2-2-6d091c736116@dawidwrobel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The "DEC0 MODE" to "DEC7 MODE" controls are enumerated, but
tx_macro_dec_mode_get() and tx_macro_dec_mode_put() access their
value through ucontrol->value.integer.value[0] (a long) instead of
ucontrol->value.enumerated.item[0] (an unsigned int).
This same pattern was fixed in the sibling drivers by
commit bcfe5f76cc ("ASoC: codecs: rx-macro: fix accessing array
out of bounds for enum type") and
commit 0ea5eff7c6 ("ASoC: codecs: va-macro: fix accessing array
out of bounds for enum type"), but tx-macro was missed.
On 64-bit kernels built with CONFIG_SND_CTL_DEBUG, the elem value
sanity check catches the 4 bytes written past the enumerated item
and every read of these controls fails with -EINVAL:
snd-sm8250 sound: control 2:0:0:DEC0 MODE:0: access overflow
Fixes: c39667ddcf ("ASoC: codecs: lpass-tx-macro: add support for lpass tx macro")
Assisted-by: Claude:claude-fable-5
Cc: stable@vger.kernel.org
Signed-off-by: Dawid Wróbel <me@dawidwrobel.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730-worktree-lpass-tx-macro-enum-fix-v2-1-6d091c736116@dawidwrobel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver-local structure was named 'snd_soc_common', which occupies
the generic snd_soc_ ASoC namespace even though it is specific to the
Qualcomm sc8280xp machine driver.
Rename the type to qcom_snd_soc_common so the identifier is properly
scoped to this driver, and rename the pointer field in
sc8280xp_snd_data from 'snd_soc_common_priv' to 'priv' so the shorter
name doesn't repeat the type name at every use.
No functional change.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260731162626.1588561-4-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Not all codecs implement the set_sysclk operation. When the board
enables codec_sysclk_set, snd_soc_dai_set_sysclk() on the codec DAI
can return -ENOTSUPP, which currently aborts hw_params and breaks
playback/capture on such boards even though the missing clock setup
is harmless.
Ignore -ENOTSUPP for the codec set_sysclk call.
Fixes: 766f3f79c3 ("ASoC: qcom: sc8280xp: enhance machine driver for board-specific config")
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260731162626.1588561-2-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Richard Acayan <mailingradian@gmail.com> says:
This adds support for the SDM660 (formerly "SDM660 internal") sound card
and support for WCD codecs over internal MI2S (represented in APIs as
LPI MI2S).
Like on MSM8916 and MSM8953, some SDM660 and SDM670 devices connect to a
digital and analog codec. The connection to the digital codec is through
special "internal" MI2S ports. The digital and analog codecs are used on
the Xiaomi Redmi Note 7 for headset (playback + capture) and earpiece,
and also on the Google Pixel 3a for the headset.
This series does not include devicetree patches.
Link: https://patch.msgid.link/20260730174353.108023-1-mailingradian@gmail.com
Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com> says:
The series first documents the WSA885X devicetree binding,
including supplies, GPIOs, Interrupt and battery configuration.
It then adds the ASoC codec driver with register programming, serial
interface setup, clock handling, mute and gain control, reset handling,
interrupt support, runtime TDM slot-count configuration, and stream-time
power-state sequencing.
validated speaker playback on Shikra and Hawi platforms.
Link: https://patch.msgid.link/20260715115220.3093799-1-prasad.kumpatla@oss.qualcomm.com
Add an ASoC codec driver for the Qualcomm WSA885X stereo smart speaker
amplifier.
The driver programs the register map, handles reset and interrupt support,
exposes DAI operations for PCM/TDM playback, and provides mixer controls
for usage mode, speaker volume and RX slot mask.
Keep stream-time power-state sequencing in the DAI callbacks and use regmap
for the control path.
Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260715115220.3093799-3-prasad.kumpatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com> says:
This series adds support for LPASS low-power resource (LPR) voting
through PRM and introduces LPASS LPI TLMM pinctrl support for newer
platforms such as Hawi.
On such platforms, LPASS requires LPR resource voting via PRM to keep
the subsystem active. This is handled by adding a new clock ID and
support for PARAM_ID_RSC_CPU_LPR in q6prm.
Additionally, a new LPASS LPI TLMM block is introduced, requiring a
dedicated DT binding and pinctrl driver.
Link: https://patch.msgid.link/20260724141708.2212057-1-prasad.kumpatla@oss.qualcomm.com
Add support for issuing LPASS low-power resource (LPR) votes through
the PRM interface.
Some platforms (e.g. Hawi) require the LPASS to be kept active via LPR
resource voting instead of the existing hardware core vote mechanism.
Handle this by introducing support for PARAM_ID_RSC_CPU_LPR when the
LPR vote clock ID is requested.
For LPR requests, use the appropriate parameter ID and payload format
to disable CPU subsystem sleep, ensuring that the LPASS register space
remains accessible.
Also add the corresponding clock mapping for LPASS_HW_LPR_VOTE.
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260724141708.2212057-4-prasad.kumpatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a new clock ID, LPASS_HW_LPR_VOTE, to represent the LPASS low-power
resource (LPR) vote through the PRM interface.
The LPASS PRM supports a resource voting mechanism to control low-power
states via PARAM_ID_RSC_CPU_LPR. Exposing this as a q6prm clock ID allows
clients to request the LPR vote using the existing qcom,q6prm clock
provider interface.
This functionality is required on newer platforms (e.g. Hawi) where LPASS
clients need to explicitly manage LPR resource voting via PRM.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260724141708.2212057-2-prasad.kumpatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The snd_sof_pcm_period_elapsed function currently schedules work on the
system-wide workqueue. This can lead to potential delays or jitter in
audio processing if the system workqueue is busy with other tasks.
To improve real-time performance and ensure timely processing of PCM
periods, we can use the system_highpri_wq instead of the default work
queue.
In performance testing, this change significantly reduced the observed
scheduling delays. For instance, under load(stressapptest -M 15000 -m
60), the maximum delay dropped from 9ms on the system workqueue to 5ms
on the dedicated high-priority workqueue.
Suggested-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Yu-Hsuan Hsu <yuhsuan@google.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20260730130445.8277-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch fixes the issue where encoder or decoder widget
types are assigned kcontrols in a topology but get ignored.
The controls were parsed successfully but were not registered
as ALSA kcontrols.
In dapm_create_or_share_kcontrol() the snd_soc_dapm_encoder
and the snd_soc_dapm_decoder are added to the switch statement
to be handled similarly as e.g. the snd_soc_dapm_effect for
assigning a proper long control name.
In dapm_widget_show_component() the snd_soc_dapm_encoder and
the snd_soc_dapm_decoder are added to switch statement to let
them to be shown in the debugfs power state output.
In snd_soc_dapm_new_widgets() the snd_soc_dapm_encoder and the
snd_soc_dapm_decoder are added to same switch case handling as
e.g. snd_soc_dapm_effect to be registered with dapm_new_pga().
The previous operation with default in the switch statement
silently ignored them. Note: Despite the function name, the
dapm_new_pga() is generic utility that calls
dapm_create_or_share_kcontrol() for each kcontrol of the widget.
Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20260730125600.6491-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> says:
We have seen cases when the delay reporting unexpectedly behaves incorrectly,
counters are not counting in hardware registers under seemingly random
conditions.
It turned out that there are few cases that the driver must handle in order
to make sure that LLP, PPLC counters are working correctly:
- non-alt links must not be reset during probe
- Concurrent (cross-direction) hazard: when SoundWire shares a physical
link DMA stream index with HDaudio, iDisp or UAOL across the two
directions, the LLP and timestamp values for the affected stream are
wrong. SSP and DMIC are not affected because every DMA request from
those links carries one sample block.
- Sequential (playback only) hazard: once a HDaudio or iDisp link has
used a playback stream index, that index cannot drive any non
HDA/iDisp link in the same direction until the next controller
reset (CRST#).
For users the impact was not visible as the link counter issue only affected
the delay reporting which already have defensive path to filter out
incorrect delays and the DSP caused delay for normal PCMs are negligible to
cause A/V sync issues for example.
Link: https://patch.msgid.link/20260730125130.29887-1-peter.ujfalusi@linux.intel.com
On ACE2+ platforms the link DMA stream allocator must avoid two
hardware errata in mlink-capable systems:
- Concurrent (cross-direction) hazard: when SoundWire shares a physical
link DMA stream index with HDaudio, iDisp or UAOL across the two
directions, the LLP and timestamp values for the affected stream are
wrong. SSP and DMIC are not affected because every DMA request from
those links carries one sample block.
- Sequential (playback only) hazard: once a HDaudio or iDisp link has
used a playback stream index, that index cannot drive any non
HDA/iDisp link in the same direction until the next controller
reset (CRST#).
Track the active link type per direction in two masks (one for SoundWire,
one for HDA/iDisp/UAOL) and the persistent set of playback stream
indices touched by HDA/iDisp in a third mask. The link DMA allocator
skips streams that would violate either rule. Streams are released from
the active masks when the stream is released; all masks are cleared in
hda_dsp_ctrl_init_chip() because the CRST# performed there clears the
hardware state as well.
A new helper hda_bus_ml_link_get_type() returns the link type from the
existing extended link descriptor so the SOF allocator can tell
SoundWire, HDA/iDisp and UAOL apart without duplicating the parsing.
The implementation is generic. On platforms older than ACE2 every link
is reported as HDA, only the sequential mask is ever set and it has no
effect because no other link types are present, so behavior is
unchanged.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://patch.msgid.link/20260730125130.29887-5-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Drop the hda_bus_ml_put_all() call at the end of hda_init_caps().
On multi-link (mlink) capable platforms the non-alternate links
(HDaudio and iDisp) are powered on by hardware when CRST# is
de-asserted (LCTL.SPA = 1) and their ref_count is pre-charged to 1 in
hda_ml_alloc_h2link() to match this state. The put_all call
immediately dropped that reference and toggled LCTL.SPA back to 0,
relying on the first stream open to power the link up again.
On ACE2+ platforms this redundant SPA 1->0->1 toggle at probe leaves
the Processing Pipe Capability (PPLC) Linear Link Position counters in
a state where they do not advance on the first stream after boot. The
counters only start working after the first full runtime suspend/resume
cycle, which includes a CRST# assert/deassert that fully resets the PPC
AON block.
Keep the non-alt links powered from CRST# de-assert through first use.
System suspend still powers them down via hda_bus_ml_suspend(), and
resume relies on CRST# de-assert to bring them back up, so no other
path is affected.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://patch.msgid.link/20260730125130.29887-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Move the hda_bus_ml_init() call from hda_init_caps() into
hda_dsp_ctrl_init_chip(), right after the HDA controller reset has
been de-asserted and unsolicited responses have been accepted.
hda_dsp_ctrl_init_chip() already calls hda_bus_ml_reset_losidv() at
the end of its sequence to clear the stream-to-link mapping. On first
boot this call was a no-op because the multi-link list had not yet
been populated: hda_bus_ml_init() only runs later in hda_init_caps().
Enumerating the links inside init_chip() makes the LOSIDV reset
effective on first boot as well, without adding a second reset call
from the probe path.
hda_bus_ml_init() now returns early when the hlink_list is already
populated, so the subsequent invocations from the D3 resume path
(hda_resume() -> hda_dsp_ctrl_init_chip(false)) are no-ops.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://patch.msgid.link/20260730125130.29887-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Mark Brown
bui duc phuc
Kuninori Morimoto
Dawid Wróbel
Srinivas Kandagatla
Neil Armstrong
Richard Acayan
Vladimir Lypak
Adam Skladowski
Nickolay Goppen
Prasad Kumpatla
Yu-Hsuan Hsu
Seppo Ingalsuo
Peter Ujfalusi