All of lore.kernel.org
 help / color / mirror / Atom feed
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 0/3] soundwire: pm runtime improvements
Date: Wed, 20 Apr 2022 10:32:38 +0800	[thread overview]
Message-ID: <20220420023241.14335-1-yung-chuan.liao@linux.intel.com> (raw)

This series provides a solution to solve a corner case issue 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.

Pierre-Louis Bossart (3):
  soundwire: intel: prevent pm_runtime resume prior to system suspend
  soundwire: intel: disable WAKEEN in pm_runtime resume
  soundwire: bus: pm_runtime_request_resume on peripheral attachment

 drivers/soundwire/bus.c   | 12 ++++++++++++
 drivers/soundwire/intel.c |  6 ++++++
 2 files changed, 18 insertions(+)

-- 
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, 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 0/3] soundwire: pm runtime improvements
Date: Wed, 20 Apr 2022 10:32:38 +0800	[thread overview]
Message-ID: <20220420023241.14335-1-yung-chuan.liao@linux.intel.com> (raw)

This series provides a solution to solve a corner case issue 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.

Pierre-Louis Bossart (3):
  soundwire: intel: prevent pm_runtime resume prior to system suspend
  soundwire: intel: disable WAKEEN in pm_runtime resume
  soundwire: bus: pm_runtime_request_resume on peripheral attachment

 drivers/soundwire/bus.c   | 12 ++++++++++++
 drivers/soundwire/intel.c |  6 ++++++
 2 files changed, 18 insertions(+)

-- 
2.17.1


             reply	other threads:[~2022-04-20  2:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20  2:32 Bard Liao [this message]
2022-04-20  2:32 ` [PATCH 0/3] soundwire: pm runtime improvements 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 ` [PATCH 3/3] soundwire: bus: pm_runtime_request_resume on peripheral attachment Bard Liao
2022-04-20  2:32   ` 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-1-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: link
Be 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.