From: Bard Liao <yung-chuan.liao@linux.intel.com> To: alsa-devel@alsa-project.org, vkoul@kernel.org Cc: vinod.koul@linaro.org, linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org, srinivas.kandagatla@linaro.org, pierre-louis.bossart@linux.intel.com, sanyog.r.kale@intel.com, bard.liao@intel.com Subject: [PATCH 3/3] soundwire: bus: pm_runtime_request_resume on peripheral attachment Date: Wed, 20 Apr 2022 10:32:41 +0800 [thread overview] Message-ID: <20220420023241.14335-4-yung-chuan.liao@linux.intel.com> (raw) In-Reply-To: <20220420023241.14335-1-yung-chuan.liao@linux.intel.com> From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> In typical use cases, the peripheral becomes pm_runtime active as a result of the ALSA/ASoC framework starting up a DAI. The parent/child hierarchy guarantees that the manager device will be fully resumed beforehand. There is however a corner case where the manager device may become pm_runtime active, but without ALSA/ASoC requesting any functionality from the peripherals. In this case, the hardware peripheral device will report as ATTACHED and its initialization routine will be executed. If this initialization routine initiates any sort of deferred processing, there is a possibility that the manager could suspend without the peripheral suspend sequence being invoked: from the pm_runtime framework perspective, the peripheral is *already* suspended. To avoid such disconnects between hardware state and pm_runtime state, this patch adds an asynchronous pm_request_resume() upon successful attach/initialization which will result in the proper resume/suspend sequence to be followed on the peripheral side. BugLink: https://github.com/thesofproject/linux/issues/3459 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> --- drivers/soundwire/bus.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c index 354d3f89366f..8b7a680f388e 100644 --- a/drivers/soundwire/bus.c +++ b/drivers/soundwire/bus.c @@ -1838,6 +1838,18 @@ int sdw_handle_slave_status(struct sdw_bus *bus, __func__, slave->dev_num); complete(&slave->initialization_complete); + + /* + * If the manager became pm_runtime active, the peripherals will be + * restarted and attach, but their pm_runtime status may remain + * suspended. If the 'update_slave_status' callback initiates + * any sort of deferred processing, this processing would not be + * cancelled on pm_runtime suspend. + * To avoid such zombie states, we queue a request to resume. + * This would be a no-op in case the peripheral was being resumed + * by e.g. the ALSA/ASoC framework. + */ + pm_request_resume(&slave->dev); } } -- 2.17.1
WARNING: multiple messages have this Message-ID (diff)
From: Bard Liao <yung-chuan.liao@linux.intel.com> To: alsa-devel@alsa-project.org, vkoul@kernel.org Cc: vinod.koul@linaro.org, gregkh@linuxfoundation.org, pierre-louis.bossart@linux.intel.com, linux-kernel@vger.kernel.org, srinivas.kandagatla@linaro.org, sanyog.r.kale@intel.com, bard.liao@intel.com Subject: [PATCH 3/3] soundwire: bus: pm_runtime_request_resume on peripheral attachment Date: Wed, 20 Apr 2022 10:32:41 +0800 [thread overview] Message-ID: <20220420023241.14335-4-yung-chuan.liao@linux.intel.com> (raw) In-Reply-To: <20220420023241.14335-1-yung-chuan.liao@linux.intel.com> From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> In typical use cases, the peripheral becomes pm_runtime active as a result of the ALSA/ASoC framework starting up a DAI. The parent/child hierarchy guarantees that the manager device will be fully resumed beforehand. There is however a corner case where the manager device may become pm_runtime active, but without ALSA/ASoC requesting any functionality from the peripherals. In this case, the hardware peripheral device will report as ATTACHED and its initialization routine will be executed. If this initialization routine initiates any sort of deferred processing, there is a possibility that the manager could suspend without the peripheral suspend sequence being invoked: from the pm_runtime framework perspective, the peripheral is *already* suspended. To avoid such disconnects between hardware state and pm_runtime state, this patch adds an asynchronous pm_request_resume() upon successful attach/initialization which will result in the proper resume/suspend sequence to be followed on the peripheral side. BugLink: https://github.com/thesofproject/linux/issues/3459 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> --- drivers/soundwire/bus.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c index 354d3f89366f..8b7a680f388e 100644 --- a/drivers/soundwire/bus.c +++ b/drivers/soundwire/bus.c @@ -1838,6 +1838,18 @@ int sdw_handle_slave_status(struct sdw_bus *bus, __func__, slave->dev_num); complete(&slave->initialization_complete); + + /* + * If the manager became pm_runtime active, the peripherals will be + * restarted and attach, but their pm_runtime status may remain + * suspended. If the 'update_slave_status' callback initiates + * any sort of deferred processing, this processing would not be + * cancelled on pm_runtime suspend. + * To avoid such zombie states, we queue a request to resume. + * This would be a no-op in case the peripheral was being resumed + * by e.g. the ALSA/ASoC framework. + */ + pm_request_resume(&slave->dev); } } -- 2.17.1
next prev parent reply other threads:[~2022-04-20 2:33 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-20 2:32 [PATCH 0/3] soundwire: pm runtime improvements Bard Liao 2022-04-20 2:32 ` Bard Liao 2022-04-20 2:32 ` [PATCH 1/3] soundwire: intel: prevent pm_runtime resume prior to system suspend Bard Liao 2022-04-20 2:32 ` Bard Liao 2022-04-20 2:32 ` [PATCH 2/3] soundwire: intel: disable WAKEEN in pm_runtime resume Bard Liao 2022-04-20 2:32 ` Bard Liao 2022-04-20 2:32 ` Bard Liao [this message] 2022-04-20 2:32 ` [PATCH 3/3] soundwire: bus: pm_runtime_request_resume on peripheral attachment Bard Liao 2022-05-09 6:31 ` [PATCH 0/3] soundwire: pm runtime improvements Vinod Koul 2022-05-09 6:31 ` Vinod Koul
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220420023241.14335-4-yung-chuan.liao@linux.intel.com \ --to=yung-chuan.liao@linux.intel.com \ --cc=alsa-devel@alsa-project.org \ --cc=bard.liao@intel.com \ --cc=gregkh@linuxfoundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=pierre-louis.bossart@linux.intel.com \ --cc=sanyog.r.kale@intel.com \ --cc=srinivas.kandagatla@linaro.org \ --cc=vinod.koul@linaro.org \ --cc=vkoul@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.