[PATCH v2] soundwire: intel_auxdevice: Fix system suspend/resume handling

Rafael J. Wysocki posted 1 patch 9 months, 2 weeks ago
drivers/soundwire/intel_auxdevice.c |   36 +++++++++++++-----------------------
1 file changed, 13 insertions(+), 23 deletions(-)
[PATCH v2] soundwire: intel_auxdevice: Fix system suspend/resume handling
Posted by Rafael J. Wysocki 9 months, 2 weeks ago
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Before commit bca84a7b93fd ("PM: sleep: Use DPM_FLAG_SMART_SUSPEND
conditionally") the runtime PM status of the device in intel_resume()
had always been RPM_ACTIVE because setting DPM_FLAG_SMART_SUSPEND had
caused the core to call pm_runtime_set_active() for that device during
the "noirq" resume phase.  For this reason, the pm_runtime_suspended()
check in intel_resume() had never triggered and the code depending on
it had never run.  That had not caused any observable functional issues
to appear, so effectively the code in question had never been needed.

After commit bca84a7b93fd the core does not call pm_runtime_set_active()
for all devices with DPM_FLAG_SMART_SUSPEND set any more and the code
depending on the pm_runtime_suspended() check in intel_resume() runs if
the device is runtime-suspended prior to a system-wide suspend
transition.  Unfortunately, when it runs, it breaks things due to the
attempt to runtime-resume bus->dev which most likely is not ready for a
runtime resume at that point.

It also does other more-or-less questionable things.  Namely, it
calls pm_runtime_idle() for a device with a nonzero runtime PM usage
counter which has no effect (all devices have nonzero runtime PM
usage counters during system-wide suspend and resume).  It also calls
pm_runtime_mark_last_busy() for the device even though devices cannot
runtime-suspend during system-wide suspend and resume (because their
runtime PM usage counters are nonzero) and an analogous call is made
in the same function later.  Moreover, it sets the runtime PM status
of the device to RPM_ACTIVE before activating it.

For the reasons listed above, remove that code altogether.

On top of that, add a pm_runtime_disable() call to intel_suspend() to
prevent the device from being runtime-resumed at any point after
intel_suspend() has started to manipulate it because the changes
made by that function would be undone by a runtime-suspend of the
device.

Next, once runtime PM has been disabled, the runtime PM status of the
device cannot change, so pm_runtime_status_suspended() can be used
instead of pm_runtime_suspended() in intel_suspend().

Finally, make intel_resume() call pm_runtime_set_active() at the end to
set the runtime PM status of the device to "active" because it has just
been activated and re-enable runtime PM for it after that.

Additionally, drop the setting of DPM_FLAG_SMART_SUSPEND from the
driver because it has no effect on devices handled by it.

Fixes: bca84a7b93fd ("PM: sleep: Use DPM_FLAG_SMART_SUSPEND conditionally")
Reported-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Tested-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---

v1 -> v2: New changelog

Since it fixes a recent regression in 6.15-rc, I can route it through the
PM tree unless that would be a major concern.

---
 drivers/soundwire/intel_auxdevice.c |   36 +++++++++++++-----------------------
 1 file changed, 13 insertions(+), 23 deletions(-)

--- a/drivers/soundwire/intel_auxdevice.c
+++ b/drivers/soundwire/intel_auxdevice.c
@@ -353,9 +353,6 @@
 	/* use generic bandwidth allocation algorithm */
 	sdw->cdns.bus.compute_params = sdw_compute_params;
 
-	/* avoid resuming from pm_runtime suspend if it's not required */
-	dev_pm_set_driver_flags(dev, DPM_FLAG_SMART_SUSPEND);
-
 	ret = sdw_bus_master_add(bus, dev, dev->fwnode);
 	if (ret) {
 		dev_err(dev, "sdw_bus_master_add fail: %d\n", ret);
@@ -640,7 +637,10 @@
 		return 0;
 	}
 
-	if (pm_runtime_suspended(dev)) {
+	/* Prevent runtime PM from racing with the code below. */
+	pm_runtime_disable(dev);
+
+	if (pm_runtime_status_suspended(dev)) {
 		dev_dbg(dev, "pm_runtime status: suspended\n");
 
 		clock_stop_quirks = sdw->link_res->clock_stop_quirks;
@@ -648,7 +648,7 @@
 		if ((clock_stop_quirks & SDW_INTEL_CLK_STOP_BUS_RESET) ||
 		    !clock_stop_quirks) {
 
-			if (pm_runtime_suspended(dev->parent)) {
+			if (pm_runtime_status_suspended(dev->parent)) {
 				/*
 				 * paranoia check: this should not happen with the .prepare
 				 * resume to full power
@@ -715,7 +715,6 @@
 	struct sdw_cdns *cdns = dev_get_drvdata(dev);
 	struct sdw_intel *sdw = cdns_to_intel(cdns);
 	struct sdw_bus *bus = &cdns->bus;
-	int link_flags;
 	int ret;
 
 	if (bus->prop.hw_disabled || !sdw->startup_done) {
@@ -724,23 +723,6 @@
 		return 0;
 	}
 
-	if (pm_runtime_suspended(dev)) {
-		dev_dbg(dev, "pm_runtime status was suspended, forcing active\n");
-
-		/* follow required sequence from runtime_pm.rst */
-		pm_runtime_disable(dev);
-		pm_runtime_set_active(dev);
-		pm_runtime_mark_last_busy(dev);
-		pm_runtime_enable(dev);
-
-		pm_runtime_resume(bus->dev);
-
-		link_flags = md_flags >> (bus->link_id * 8);
-
-		if (!(link_flags & SDW_INTEL_MASTER_DISABLE_PM_RUNTIME_IDLE))
-			pm_runtime_idle(dev);
-	}
-
 	ret = sdw_intel_link_power_up(sdw);
 	if (ret) {
 		dev_err(dev, "%s failed: %d\n", __func__, ret);
@@ -761,6 +743,14 @@
 	}
 
 	/*
+	 * Runtime PM has been disabled in intel_suspend(), so set the status
+	 * to active because the device has just been resumed and re-enable
+	 * runtime PM.
+	 */
+	pm_runtime_set_active(dev);
+	pm_runtime_enable(dev);
+
+	/*
 	 * after system resume, the pm_runtime suspend() may kick in
 	 * during the enumeration, before any children device force the
 	 * master device to remain active.  Using pm_runtime_get()
Re: [PATCH v2] soundwire: intel_auxdevice: Fix system suspend/resume handling
Posted by Liao, Bard 9 months, 2 weeks ago

On 4/29/2025 3:50 AM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> Before commit bca84a7b93fd ("PM: sleep: Use DPM_FLAG_SMART_SUSPEND
> conditionally") the runtime PM status of the device in intel_resume()
> had always been RPM_ACTIVE because setting DPM_FLAG_SMART_SUSPEND had
> caused the core to call pm_runtime_set_active() for that device during
> the "noirq" resume phase.  For this reason, the pm_runtime_suspended()
> check in intel_resume() had never triggered and the code depending on
> it had never run.  That had not caused any observable functional issues
> to appear, so effectively the code in question had never been needed.
> 
> After commit bca84a7b93fd the core does not call pm_runtime_set_active()
> for all devices with DPM_FLAG_SMART_SUSPEND set any more and the code
> depending on the pm_runtime_suspended() check in intel_resume() runs if
> the device is runtime-suspended prior to a system-wide suspend
> transition.  Unfortunately, when it runs, it breaks things due to the
> attempt to runtime-resume bus->dev which most likely is not ready for a
> runtime resume at that point.
> 
> It also does other more-or-less questionable things.  Namely, it
> calls pm_runtime_idle() for a device with a nonzero runtime PM usage
> counter which has no effect (all devices have nonzero runtime PM
> usage counters during system-wide suspend and resume).  It also calls
> pm_runtime_mark_last_busy() for the device even though devices cannot
> runtime-suspend during system-wide suspend and resume (because their
> runtime PM usage counters are nonzero) and an analogous call is made
> in the same function later.  Moreover, it sets the runtime PM status
> of the device to RPM_ACTIVE before activating it.
> 
> For the reasons listed above, remove that code altogether.
> 
> On top of that, add a pm_runtime_disable() call to intel_suspend() to
> prevent the device from being runtime-resumed at any point after
> intel_suspend() has started to manipulate it because the changes
> made by that function would be undone by a runtime-suspend of the
> device.
> 
> Next, once runtime PM has been disabled, the runtime PM status of the
> device cannot change, so pm_runtime_status_suspended() can be used
> instead of pm_runtime_suspended() in intel_suspend().
> 
> Finally, make intel_resume() call pm_runtime_set_active() at the end to
> set the runtime PM status of the device to "active" because it has just
> been activated and re-enable runtime PM for it after that.
> 
> Additionally, drop the setting of DPM_FLAG_SMART_SUSPEND from the
> driver because it has no effect on devices handled by it.
> 
> Fixes: bca84a7b93fd ("PM: sleep: Use DPM_FLAG_SMART_SUSPEND conditionally")
> Reported-by: Bard Liao <yung-chuan.liao@linux.intel.com>
> Tested-by: Bard Liao <yung-chuan.liao@linux.intel.com>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> 
> v1 -> v2: New changelog
> 
> Since it fixes a recent regression in 6.15-rc, I can route it through the
> PM tree unless that would be a major concern.
> 

 Acked-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Re: [PATCH v2] soundwire: intel_auxdevice: Fix system suspend/resume handling
Posted by Rafael J. Wysocki 9 months, 1 week ago
On Wed, Apr 30, 2025 at 2:59 AM Liao, Bard
<yung-chuan.liao@linux.intel.com> wrote:
>
>
>
> On 4/29/2025 3:50 AM, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > Before commit bca84a7b93fd ("PM: sleep: Use DPM_FLAG_SMART_SUSPEND
> > conditionally") the runtime PM status of the device in intel_resume()
> > had always been RPM_ACTIVE because setting DPM_FLAG_SMART_SUSPEND had
> > caused the core to call pm_runtime_set_active() for that device during
> > the "noirq" resume phase.  For this reason, the pm_runtime_suspended()
> > check in intel_resume() had never triggered and the code depending on
> > it had never run.  That had not caused any observable functional issues
> > to appear, so effectively the code in question had never been needed.
> >
> > After commit bca84a7b93fd the core does not call pm_runtime_set_active()
> > for all devices with DPM_FLAG_SMART_SUSPEND set any more and the code
> > depending on the pm_runtime_suspended() check in intel_resume() runs if
> > the device is runtime-suspended prior to a system-wide suspend
> > transition.  Unfortunately, when it runs, it breaks things due to the
> > attempt to runtime-resume bus->dev which most likely is not ready for a
> > runtime resume at that point.
> >
> > It also does other more-or-less questionable things.  Namely, it
> > calls pm_runtime_idle() for a device with a nonzero runtime PM usage
> > counter which has no effect (all devices have nonzero runtime PM
> > usage counters during system-wide suspend and resume).  It also calls
> > pm_runtime_mark_last_busy() for the device even though devices cannot
> > runtime-suspend during system-wide suspend and resume (because their
> > runtime PM usage counters are nonzero) and an analogous call is made
> > in the same function later.  Moreover, it sets the runtime PM status
> > of the device to RPM_ACTIVE before activating it.
> >
> > For the reasons listed above, remove that code altogether.
> >
> > On top of that, add a pm_runtime_disable() call to intel_suspend() to
> > prevent the device from being runtime-resumed at any point after
> > intel_suspend() has started to manipulate it because the changes
> > made by that function would be undone by a runtime-suspend of the
> > device.
> >
> > Next, once runtime PM has been disabled, the runtime PM status of the
> > device cannot change, so pm_runtime_status_suspended() can be used
> > instead of pm_runtime_suspended() in intel_suspend().
> >
> > Finally, make intel_resume() call pm_runtime_set_active() at the end to
> > set the runtime PM status of the device to "active" because it has just
> > been activated and re-enable runtime PM for it after that.
> >
> > Additionally, drop the setting of DPM_FLAG_SMART_SUSPEND from the
> > driver because it has no effect on devices handled by it.
> >
> > Fixes: bca84a7b93fd ("PM: sleep: Use DPM_FLAG_SMART_SUSPEND conditionally")
> > Reported-by: Bard Liao <yung-chuan.liao@linux.intel.com>
> > Tested-by: Bard Liao <yung-chuan.liao@linux.intel.com>
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > ---
> >
> > v1 -> v2: New changelog
> >
> > Since it fixes a recent regression in 6.15-rc, I can route it through the
> > PM tree unless that would be a major concern.
> >
>
>  Acked-by: Bard Liao <yung-chuan.liao@linux.intel.com>

Thanks, applied.