Re: [PATCH] ASoC: cs35l41: Restore register state after system sleep

["Nícolas F. R. A. Prado" <nfraprado@collabora.com>]

On Wed, 2026-06-17 at 12:40 -0500, Rhodes, David wrote:
> On 6/16/26 11:31 AM, Stefan Binding wrote:
> > Hi,
> > 
> > I have some concerns about this patch.
> > 
> > This driver is used for more than just the Steam Deck, so we would
> > need to ensure that this patch doesn't break those systems.
> > There are some potential complexities around cs35l41 with respect
> > to Boost and DSP enablement that need careful thought when
> > supporting system sleep.
> > 
> > The HDA equivalent driver for cs35l41 does have support for system
> > sleep, but this driver works very differently.
> > 
> > I recommend reaching out to David Rhodes <david.rhodes@cirrus.com>
> > for more information on the ASoC driver for CS35L41.
> > Please also cc patches@opensource.cirrus.com.
> > 
> > Thanks,
> > 
> > Stefan
> > 
> > On 15/06/2026 15:54, Nícolas F. R. A. Prado wrote:
> > > Currently, on the Steam Deck LCD when the system goes into
> > > hibernation
> > > and resumes back, the speakers are silent when playing with:
> > > 
> > >    aplay -D plughw:acp5x,1 /usr/share/sounds/alsa/Front_Left.wav
> > > 
> > > A crude workaround was to, after resuming the system, bypassing
> > > the
> > > regmap cache on the cs35l41 devices, before playing:
> > > 
> > >    echo 1 > /sys/kernel/debug/regmap/spi-VLV1776\:00/cache_bypass
> > >    echo 1 > /sys/kernel/debug/regmap/spi-VLV1776\:01/cache_bypass
> > > 
> > > That indicated that the hardware registers had gone out of sync
> > > with
> > > the regmap cache due to the power down in system hibernation.
> > > 
> > > Fix the issue by, before system sleep, marking the regcache as
> > > cache
> > > only, and after system sleep, resetting the hardware and
> > > restoring the
> > > hardware registers from the regcache.
> > > 
> > > This gets the sound working on the Steam Deck LCD after resume
> > > from S4.
> > > 
> > > While the issue was only observed on S4 on this platform, the
> > > callbacks
> > > for suspend/resume are also set in the same way to account for
> > > platforms
> > > that might power down the chip on S3 as well.
> > > 
> > > Note that this change does not take care of restoring the DSP
> > > state,
> > > since the affected platform does not use the DSP and it couldn't
> > > be
> > > tested, so it is only shut down on resume so it can be
> > > reinitialized in
> > > a future DSP preload event.
> > > 
> > > Assisted-by: Copilot:claude-sonnet-4.6
> > > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> 
> Hi Nicholas,
> 
> I share Stefan's concerns about this patch affecting other devices. I
> also wonder if there is a less crude workaround for your system's
> behavior.
> 
> The existing driver uses runtime_suspend/runtime_resume to enter and 
> exit a low power 'hibernation' mode 
> (wm_adsp_hibernate/cs35l41_enter_hibernate). In this mode the part
> will 
> lose some configuration so the regmap is put into cache_only for the 
> duration of the sleep and synced when waking up.
> 
> Are you sure the device is not just missing a runtime_resume after
> the 
> system is in S4? This whole sequence of sys operations should only be
> needed if the amp is completely losing power.

Hi David, Stefan,

The current PM runtime logic is to runtime-resume the device before
carrying out the system PM callbacks, and only allow runtime-suspend
after the system has resumed back. So during S4 the device is runtime-
resumed.

Also, since on my system the DSP is not used, the early return in the
runtime suspend/resume `if (!cs35l41->dsp.preloaded || !cs35l41-
>dsp.cs_dsp.running)` means that the runtime suspend/resume callbacks
are no-ops on my system.

Nonetheless, I tried simply marking the regcache dirty and syncing it
upon system resume, mimicking the runtime suspend/resume, as follows:

diff --git a/sound/soc/codecs/cs35l41.c b/sound/soc/codecs/cs35l41.c
index 5001a546a3e7..5933d61753d8 100644
--- a/sound/soc/codecs/cs35l41.c
+++ b/sound/soc/codecs/cs35l41.c
@@ -1445,6 +1445,9 @@ static int cs35l41_sys_suspend(struct device
*dev)
 {
        struct cs35l41_private *cs35l41 = dev_get_drvdata(dev);
 
+       regcache_cache_only(cs35l41->regmap, true);
+       regcache_mark_dirty(cs35l41->regmap);
+
        dev_dbg(cs35l41->dev, "System suspend, disabling IRQ\n");
        disable_irq(cs35l41->irq);
 
@@ -1474,10 +1477,23 @@ static int cs35l41_sys_resume_noirq(struct
device *dev)
 static int cs35l41_sys_resume(struct device *dev)
 {
        struct cs35l41_private *cs35l41 = dev_get_drvdata(dev);
+       int ret;
 
        dev_dbg(cs35l41->dev, "System resume, reenabling IRQ\n");
        enable_irq(cs35l41->irq);
 
+       regcache_cache_only(cs35l41->regmap, false);
+
+       /* Test key needs to be unlocked to allow the OTP settings to
re-apply */
+       cs35l41_test_key_unlock(cs35l41->dev, cs35l41->regmap);
+       ret = regcache_sync(cs35l41->regmap);
+       cs35l41_test_key_lock(cs35l41->dev, cs35l41->regmap);
+       if (ret) {
+               dev_err(cs35l41->dev, "Failed to restore register
cache: %d\n", ret);
+               return ret;
+       }
+       cs35l41_init_boost(cs35l41->dev, cs35l41->regmap, &cs35l41-
>hw_cfg);
+
        return 0;
 }


With just this change, the first playback after resume from S4 works,
but I see in dmesg:

[  133.019606] cs35l41 spi-VLV1776:00: Enable(0) failed: -110
[  133.019896] cs35l41 spi-VLV1776:00: ASoC: POST_PMD: Left Main AMP
event failed: -110
[  133.124515] cs35l41 spi-VLV1776:01: Enable(0) failed: -110
[  133.124831] cs35l41 spi-VLV1776:01: ASoC: POST_PMD: Right Main AMP
event failed: -110

Which points to CS35L41_IRQ1_STATUS1 reads timing out. Subsequent
attempts to playback sound are completely silent and the same error is
printed.

Given that my patch that fully reinitializes the hardware works, while
this doesn't, I'm inclined to believe that the chip loses power during
S4 indeed, at which point just restoring the register state is no
longer enough. But perhaps you could shed more light into this since
you're much more familiar with this hardware than I am.

Thanks,
Nícolas