[PATCH] ASoC: SDCA: Add NO_DIRECT_COMPLETE flag to class driver

[PATCH] ASoC: SDCA: Add NO_DIRECT_COMPLETE flag to class driver

[Charles Keepax]

The SDCA class driver currently expects the device will be fully powered
down on system suspend but not on runtime suspend. This is typically
required as when audio is not active (ie. runtime suspend) jack detect
is expected to still function, but when the whole system is hibernated
there is no need to recognise audio jack events. This means the class
driver needs to always be informed of a system suspend, so the direct
complete optimisation (where PM will skip calling system suspend if the
device is runtime suspended) is not appropriate for the SDCA class
driver.

Add the NO_DIRECT_COMPLETE flag to prevent this optimisation from
running against this driver.

Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
---
 sound/soc/sdca/sdca_class_function.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/sdca/sdca_class_function.c b/sound/soc/sdca/sdca_class_function.c
index 0afa41c1ee93c..98fd3fd1052b4 100644
--- a/sound/soc/sdca/sdca_class_function.c
+++ b/sound/soc/sdca/sdca_class_function.c
@@ -377,6 +377,8 @@ static int class_function_probe(struct auxiliary_device *auxdev,
 	if (ret)
 		return ret;
 
+	dev_pm_set_driver_flags(dev, DPM_FLAG_NO_DIRECT_COMPLETE);
+
 	pm_runtime_set_autosuspend_delay(dev, 200);
 	pm_runtime_use_autosuspend(dev);
 	pm_runtime_set_active(dev);
-- 
2.47.3

Re: [PATCH] ASoC: SDCA: Add NO_DIRECT_COMPLETE flag to class driver

[Pierre-Louis Bossart]

On 1/15/26 14:17, Charles Keepax wrote:
> The SDCA class driver currently expects the device will be fully powered
> down on system suspend but not on runtime suspend. This is typically
> required as when audio is not active (ie. runtime suspend) jack detect
> is expected to still function, but when the whole system is hibernated
> there is no need to recognise audio jack events. This means the class
> driver needs to always be informed of a system suspend, so the direct
> complete optimisation (where PM will skip calling system suspend if the
> device is runtime suspended) is not appropriate for the SDCA class
> driver.
> 
> Add the NO_DIRECT_COMPLETE flag to prevent this optimisation from
> running against this driver.

Humm, this flag makes sure the class driver .suspend method is called, but does the core also force a pm_runtime resume before?

In other words, what is the state of the device when the system suspend routine is invoked by the PM core when this flag is set?

FWIW, we had a similar problem on the Intel side, and we used the .prepare method to force a pm_runtime resume. If the host was pm_runtime suspended, then we'd bring it back to full power before the system suspend. It may seem overkill but it's required at the hardware level, a system suspend with the clock already stopped isn't supported.
If the PM core guaranteed the device state was resumed by adding this flag, then the Intel folks could remove quite a few lines of code.

link: https://github.com/thesofproject/linux/blob/ec0e6c69113f4b342ee8eabec286dea33d98a7cc/drivers/soundwire/intel_auxdevice.c#L568

Going back to this SDCA driver, if the PM core does NOT change the pm_runtime state, then should the class driver perform a full pm_runtime resume and then do the expected system suspend sequence?

Sorry if I am splitting hair, in the past we played with these PM flags and always understood them in the wrong way...
 
> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
> ---
>  sound/soc/sdca/sdca_class_function.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/sound/soc/sdca/sdca_class_function.c b/sound/soc/sdca/sdca_class_function.c
> index 0afa41c1ee93c..98fd3fd1052b4 100644
> --- a/sound/soc/sdca/sdca_class_function.c
> +++ b/sound/soc/sdca/sdca_class_function.c
> @@ -377,6 +377,8 @@ static int class_function_probe(struct auxiliary_device *auxdev,
>  	if (ret)
>  		return ret;
>  
> +	dev_pm_set_driver_flags(dev, DPM_FLAG_NO_DIRECT_COMPLETE);
> +
>  	pm_runtime_set_autosuspend_delay(dev, 200);
>  	pm_runtime_use_autosuspend(dev);
>  	pm_runtime_set_active(dev);

Re: [PATCH] ASoC: SDCA: Add NO_DIRECT_COMPLETE flag to class driver

[Charles Keepax]

On Tue, Jan 20, 2026 at 05:50:29PM +0100, Pierre-Louis Bossart wrote:
> On 1/15/26 14:17, Charles Keepax wrote:
> > The SDCA class driver currently expects the device will be fully powered
> > down on system suspend but not on runtime suspend. This is typically
> > required as when audio is not active (ie. runtime suspend) jack detect
> > is expected to still function, but when the whole system is hibernated
> > there is no need to recognise audio jack events. This means the class
> > driver needs to always be informed of a system suspend, so the direct
> > complete optimisation (where PM will skip calling system suspend if the
> > device is runtime suspended) is not appropriate for the SDCA class
> > driver.
> > 
> > Add the NO_DIRECT_COMPLETE flag to prevent this optimisation from
> > running against this driver.
> 
> Humm, this flag makes sure the class driver .suspend method is
> called, but does the core also force a pm_runtime resume before?

Yeah this ensures the suspend method is always called.

> In other words, what is the state of the device when the
> system suspend routine is invoked by the PM core when this
> flag is set?

Can be either runtime resumed or suspended.

> Going back to this SDCA driver, if the PM core does NOT
> change the pm_runtime state, then should the class driver
> perform a full pm_runtime resume and then do the expected
> system suspend sequence?

Yeah we do perform a resume in the system suspend although to be
honest its mostly just to force the pm_runtime_force_resume() in
the system resume handler to always do a runtime resume.

> Sorry if I am splitting hair, in the past we played with
> these PM flags and always understood them in the wrong way...

There is definitely a lot of subtlety in this part of the kernel,
hence why I CCed the PM people on this patch :-) Its a bit of an
odd optimisation this direct complete thing, as far as I can see
lots of drives don't run it without really deliberately avoiding
it. For SoundWire itself the soundwire host resumes all children
before a suspend, which dodges the direct complete. I would
imagine a lot of other peripheral buses do similar. For MFD
children they are almost always on the same fwnode as their
parent so they don't hit it either. Turns out this class driver
is the first thing I have worked on that actually hits the direct
complete optimimisation as far as I can see.

Thanks,
Charles

Re: [PATCH] ASoC: SDCA: Add NO_DIRECT_COMPLETE flag to class driver

[Pierre-Louis Bossart]

>>> The SDCA class driver currently expects the device will be fully powered
>>> down on system suspend but not on runtime suspend. This is typically
>>> required as when audio is not active (ie. runtime suspend) jack detect
>>> is expected to still function, but when the whole system is hibernated
>>> there is no need to recognise audio jack events. This means the class
>>> driver needs to always be informed of a system suspend, so the direct
>>> complete optimisation (where PM will skip calling system suspend if the
>>> device is runtime suspended) is not appropriate for the SDCA class
>>> driver.
>>>
>>> Add the NO_DIRECT_COMPLETE flag to prevent this optimisation from
>>> running against this driver.
>>
>> Humm, this flag makes sure the class driver .suspend method is
>> called, but does the core also force a pm_runtime resume before?
> 
> Yeah this ensures the suspend method is always called.
> 
>> In other words, what is the state of the device when the
>> system suspend routine is invoked by the PM core when this
>> flag is set?
> 
> Can be either runtime resumed or suspended.

ok, so if the child driver wants to resume to full power it has to be done 'manually', the PM core does not help.

>> Going back to this SDCA driver, if the PM core does NOT
>> change the pm_runtime state, then should the class driver
>> perform a full pm_runtime resume and then do the expected
>> system suspend sequence?
> 
> Yeah we do perform a resume in the system suspend although to be
> honest its mostly just to force the pm_runtime_force_resume() in
> the system resume handler to always do a runtime resume.

I think we are talking about different actions...

a) pm_runtime resume BEFORE system suspend. That would be necessary to deal with e.g. clock stop modes that are valid in pm_runtime suspend but not system suspend. It's not clear to me for example if all SDCA chips will support direct transitions from PS3 to PS4, or be ok with power rails cut while in PS3.

b) pm_runtime resume DURING system resume. That may be useful to restore functionality, but it's too late to handle problems that occur during the system suspend phase.

Either way, that's a bit orthogonal to this patch, more a discussion on how to deal with class power management.

>> Sorry if I am splitting hair, in the past we played with
>> these PM flags and always understood them in the wrong way...
> 
> There is definitely a lot of subtlety in this part of the kernel,
> hence why I CCed the PM people on this patch :-) Its a bit of an
> odd optimisation this direct complete thing, as far as I can see
> lots of drives don't run it without really deliberately avoiding
> it. For SoundWire itself the soundwire host resumes all children
> before a suspend, which dodges the direct complete. I would
> imagine a lot of other peripheral buses do similar. For MFD
> children they are almost always on the same fwnode as their
> parent so they don't hit it either. Turns out this class driver
> is the first thing I have worked on that actually hits the direct
> complete optimimisation as far as I can see.

You lost me with this sentence:

"
For SoundWire itself the soundwire host resumes all children
before a suspend, which dodges the direct complete.
"

If the direct-complete optimization is not used, then do you actually see a different behavior with this NO_DIRECT_COMPLETE flag set?

Re: [PATCH] ASoC: SDCA: Add NO_DIRECT_COMPLETE flag to class driver

[Charles Keepax]

On Wed, Jan 21, 2026 at 01:41:31PM +0100, Pierre-Louis Bossart wrote:
> >> Going back to this SDCA driver, if the PM core does NOT
> >> change the pm_runtime state, then should the class driver
> >> perform a full pm_runtime resume and then do the expected
> >> system suspend sequence?
> > 
> > Yeah we do perform a resume in the system suspend although to be
> > honest its mostly just to force the pm_runtime_force_resume() in
> > the system resume handler to always do a runtime resume.
> 
> I think we are talking about different actions...
> 
> a) pm_runtime resume BEFORE system suspend. That would be
> necessary to deal with e.g. clock stop modes that are valid in
> pm_runtime suspend but not system suspend. It's not clear to me
> for example if all SDCA chips will support direct transitions
> from PS3 to PS4, or be ok with power rails cut while in PS3.

I mean I think this is currently handled at the soundwire level,
since the soundwire bus runtime resumes all children for system
suspend.

> You lost me with this sentence:
> 
> "
> For SoundWire itself the soundwire host resumes all children
> before a suspend, which dodges the direct complete.
> "
> 
> If the direct-complete optimization is not used, then do you
> actually see a different behavior with this NO_DIRECT_COMPLETE
> flag set?

The flag is applied to the auxiliary device children of the
soundwire device. The direct complete doesn't affect the
soundwire device, but it it does affect the function devices
children.

Thanks,
Charles

Re: [PATCH] ASoC: SDCA: Add NO_DIRECT_COMPLETE flag to class driver

[Pierre-Louis Bossart]

>> You lost me with this sentence:
>>
>> "
>> For SoundWire itself the soundwire host resumes all children
>> before a suspend, which dodges the direct complete.
>> "
>>
>> If the direct-complete optimization is not used, then do you
>> actually see a different behavior with this NO_DIRECT_COMPLETE
>> flag set?
> 
> The flag is applied to the auxiliary device children of the
> soundwire device. The direct complete doesn't affect the
> soundwire device, but it it does affect the function devices
> children.

Ah ok, yes the host only resumes devices one level down, so the function level isn't affected by the .prepare logic.

I guess I was confused by the 'class driver' title  but the change is not in sdca_class.c but in sdca_class_function.c...

The change looks good, so here's my 

Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>

Re: [PATCH] ASoC: SDCA: Add NO_DIRECT_COMPLETE flag to class driver

[Mark Brown]

On Thu, 15 Jan 2026 13:17:26 +0000, Charles Keepax wrote:
> The SDCA class driver currently expects the device will be fully powered
> down on system suspend but not on runtime suspend. This is typically
> required as when audio is not active (ie. runtime suspend) jack detect
> is expected to still function, but when the whole system is hibernated
> there is no need to recognise audio jack events. This means the class
> driver needs to always be informed of a system suspend, so the direct
> complete optimisation (where PM will skip calling system suspend if the
> device is runtime suspended) is not appropriate for the SDCA class
> driver.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] ASoC: SDCA: Add NO_DIRECT_COMPLETE flag to class driver
      commit: 702ce71d32f2c30b4f45b7c6b701d87583c58df8

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark