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
The codec version CAJON_2_0 on the Snapdragon 670 requires touching the
HPH test registers. Add the quirk so this driver can also support
SDM670.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Link: https://patch.msgid.link/20260730174353.108023-16-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add regs overrides for PM8950 codec and implement matching reg overrides
via compatible.
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Link: https://patch.msgid.link/20260730174353.108023-14-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the compatible for SDM660 and SDM670 devices, which can use the
support for WCD codecs connected to internal MI2S.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-13-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The LPI_MI2S_RX_0 and LPI_MI2S_TX_3 ports on SDM660 can be connected to
the digital and analog WCD codecs. They can be supported with the same
logic for other ports, but just need to be explicitly stated. Add
support for these ports.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-12-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
On SDM660, LPI MI2S ports can be connected to a WCD codec which may
support headphones. Register the headphone jack on codecs connected to
the playback port, LPI_MI2S_RX_0.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-11-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the ASM-AFE routing for LPI MI2S ports which represent internal MI2S
ports on SDM660.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-10-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The bindings for LPI MI2S ports, originally exclusive to q6apm, can be
used for internal MI2S ports on q6afe. Add the internal MI2S ports found
on the SDM660 internal sound card using the LPI MI2S bindings.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-9-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The bindings for LPI MI2S ports, originally exclusive to q6apm, can be
used for internal MI2S ports on q6afe. Add the port mappings for
internal MI2S, found on the Snapdragon 660 internal sound card.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-8-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The MSM8916 digital codec is also found on SDM660, typically connected to
the SDM660 internal sound card. Provide a space
for specific compatibles and add the compatible for SDM660.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-6-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The PM8953 (cajon 2.0) revision of the PM8916 analog codec is also found
on PM660L, typically connected to the SDM660 internal sound card via the
digital codec. Provide a space for specific compatibles and add the
compatible for PM660L.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-5-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Document pm8950 and pm8953 analog audio codecs.
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
[richard: add back empty line]
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-4-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There are 7 internal MI2S ports per direction found on devices with the
internal sound card for Snapdragon 660. This is similar to the LPI MI2S
ports, and the LPI MI2S bindings can be reused for internal MI2S. Extend
the bindings for LPI MI2S ports to accommodate the internal MI2S ports.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-3-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add compatibles for sdm660 based soundcards.
Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260730174353.108023-2-mailingradian@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
Add bindings for the Qualcomm WSA8855 stereo smart speaker amplifier.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260715115220.3093799-2-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>
Q6DSP_MAX_CLK_ID defines the upper bound of supported clock
identifiers in the qdsp6 LPASS clock driver.
Increase the maximum clock ID value to accommodate the LPASS
LPR vote clock identifier.
Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260724141708.2212057-3-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>
The helper became unused after probe no longer drops all non-alt
links, so remove the dead API and implementation.
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-4-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>
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> says:
It is expected that the DSP is in power down state when the firmware boot
is attempted.
If the DSP for any reason was left powered up then the DSP boot will
fail since the ROM boot sequence might not be able to run.
Make sure that the DSP is off before proceeding to boot it up.
We have seen reports that for some undetermined reasons the DSP was on
during system boot and this caused firmware boot failure as the DSP
cannot be booted up - it was already in booted up state.
Link: https://patch.msgid.link/20260730122857.5294-1-peter.ujfalusi@linux.intel.com
It is expected that the DSP is in power down state when the firmware boot
is attempted.
If the DSP for any reason was left powered up then the DSP boot will
fail since the ROM boot sequence might not be able to run.
Make sure that the DSP is off before proceeding to boot it up.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@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/20260730122857.5294-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
It is expected that the DSP is in power down state when the firmware boot
is attempted.
If the DSP for any reason was left powered up then the DSP boot will
fail since the ROM boot sequence might not be able to run.
Make sure that the DSP is off before proceeding to boot it up.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@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/20260730122857.5294-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
During hw_params call we make sure that the host DMA is stopped but the
hstream->running flag is not explicitly cleared at the same time.
If the host DMA fails to stop during previous use then the flag is left
set and on next start the host DMA will be left disabled since the
trigger:STOP will skip the DMA enable.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260730122241.30541-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
bui duc phuc <phucduc.bui@gmail.com> says:
This series is the final part of the cleanup to convert ASoC codec
drivers to use the guard() and scoped_guard() helpers for mutex and
spinlock handling.
Compile-tested only.
Link: https://patch.msgid.link/20260731030648.8706-1-phucduc.bui@gmail.com
Clean up the code using guard() for mutex locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260731030648.8706-27-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Clean up the code using guard() for mutex locks.
Merely code refactoring, and no behavior change.
Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260731030648.8706-26-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Clean up the code using guard() for mutex locks.
Merely code refactoring, and no behavior change.
Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260731030648.8706-25-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Clean up the code using guard() for mutex locks.
Merely code refactoring, and no behavior change.
Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260731030648.8706-24-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Clean up the code using guard() for mutex locks.
Merely code refactoring, and no behavior change.
Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260731030648.8706-23-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Clean up the code using guard() for mutex locks.
Merely code refactoring, and no behavior change.
Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260731030648.8706-22-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Clean up the code using guard() for mutex locks.
Merely code refactoring, and no behavior change.
Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260731030648.8706-21-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Clean up the code using guard() for mutex locks.
Merely code refactoring, and no behavior change.
Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260731030648.8706-20-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Clean up the code using guard() for mutex locks.
Merely code refactoring, and no behavior change.
Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260731030648.8706-19-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Clean up the code using guard() for mutex locks.
Merely code refactoring, and no behavior change.
Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260731030648.8706-18-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Clean up the code using guard() for mutex & spin locks.
Merely code refactoring, and no behavior change.
Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260731030648.8706-17-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Clean up the code using guard() for mutex locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260731030648.8706-16-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Clean up the code using guard() for mutex locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260731030648.8706-15-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
