On Wed, Oct 29, 2025 at 05:22:26PM +0200, claudiu beznea wrote:
On 10/29/25 16:37, Mark Brown wrote:
The theory here is that the power management core uses the device instantiation order for both suspend and resume (reversed on suspend) so the fact that we use probe deferral to make sure that the card components are ready should ensure that the card suspends before anything in the card. If that is no longer the case then we need to ensure that all drivers have system PM ops which trigger the card, this won't be a driver specific issue.
I also saw the behavior described in this commit with the rz-ssi.c driver as well. The fix there was commit c1b0f5183a44 ("ASoC: renesas: rz-ssi: Use NOIRQ_SYSTEM_SLEEP_PM_OPS()").
In case of this this codec, I saw the code in da7213_runtime_resume() and soc_resume_deferred() racing each other on system resume.
So I guess we need the more general fix then, with everything calling into the core to suspend the cards.
If the device actually lost power during a runtime suspend then we'll end up having a bad time. There was also no mention of runtime PM in the patch description...
I had no issues with runtime PM, but only with suspend to RAM, when this function was called though struct dev_pm_ops::resume = pm_runtime_force_resume().
Calling regulator_disable() doesn't guarantee the regulator will be disabled, the constraints or other devices can ensure that the device retains power so there's no effect on the actual hardware.
Would keeping the regcache_cache_only() + regcache_sync() here along with populating the struct snd_soc_component_driver::{suspend, resume} be an acceptable solution for you? I think that will work as well.
I'm not sure what you're intending to populate the component with there.