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>
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>
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-14-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-13-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-11-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-10-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-9-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.
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-8-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-7-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-6-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-5-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-4-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-3-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-2-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When the peripheral re-attaches after the SoundWire controller was
power-gated during system suspend (s2idle reaching S0i3 on AMD ACP), the
amplifier has lost all of its register and DSP state. tas_update_status()
handles that by re-running tas_io_init(), which writes the device's
TAS2783_SW_RESET register - a vendor register write that clears the
device's register file and DSP state, not a SoundWire reset, so no
re-enumeration is involved - and re-downloads the firmware. Before doing
any of that, it syncs back a register cache that still holds the
pre-suspend values.
That sync is useless, since the reset immediately wipes whatever it
wrote, and it leaves the cache claiming that the amplifier is already
powered up and unmuted. Subsequent read-modify-write updates - DAPM
amplifier power-up, SDCA PDE transitions at stream start - then see "no
change" and skip the hardware write. Playback runs without a single
error while the speakers stay silent. Unbinding and rebinding the driver
restores audio, since probe starts from a fresh cache.
Drop the cache instead of syncing it when an uninitialized device
attaches, so that later accesses see the real hardware state.
Reordering the sync after tas_io_init() and marking the cache dirty is
not a workable alternative here: tas_regmap has no .writeable_reg, so
the cache accepts every register up to .max_register, including ones for
which tas2783_sdca_mbq_size() returns 0. regmap_sdw_mbq_size() rejects
those with -EINVAL, so the replay fails on the first such register and
takes initialization down with it.
Cached user settings fall back to hardware defaults across such a power
loss, which seems clearly preferable to a silent amplifier - the device
is being reset and its firmware reloaded at this point anyway.
Tested on an ASUS ProArt PX13 HN7306EAC (AMD Strix Halo, ACP7.0, two
TAS2783 amplifiers plus RT721 on SoundWire link 1): the speakers work
after an s2idle resume with ~51 s of S0i3 residency, where previously
they stayed silent despite a complete firmware re-download.
Fixes: 4cc9bd8d7b ("ASoc: tas2783A: Add soundwire based codec driver")
Reported-by: Antoine Monnet <antoine@montane.tech>
Closes: https://lore.kernel.org/all/c66ae00a-e878-4af0-a05a-272e9574eaa5@montane.tech/
Signed-off-by: Andrey Golovko <andrey.golovko@gmail.com>
Link: https://patch.msgid.link/3e2751d1fb027bed0f09c88e5e56da8f@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> says:
This series fixes some issues left to the first version
sof_ipc4_mod_init_ext_dp_memory_data payload building code. The
payload to specify memory requirements of Data Processing components,
running as independent processes in SOF firmware.
But more importantly it adds a payload of similar purpose to the
pipeline create message, e.g. sof_ipc4_glb_pipe_payload. It sums up
the memory requirements of individual Low Latency components in the
pipeline and sends the summed up values in pipeline create message.
Link: https://patch.msgid.link/20260730104141.14817-1-peter.ujfalusi@linux.intel.com
Refactor sof_ipc4_widget_mod_init_msg_payload() to be easier to extend.
Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20260730104141.14817-7-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
