From: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
To: Richard Fitzgerald <rf@opensource.cirrus.com>,
"Liao, Bard" <bard.liao@intel.com>,
Bard Liao <yung-chuan.liao@linux.intel.com>,
"linux-sound@vger.kernel.org" <linux-sound@vger.kernel.org>,
"vkoul@kernel.org" <vkoul@kernel.org>
Cc: "vinod.koul@linaro.org" <vinod.koul@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"peter.ujfalusi@linux.intel.com" <peter.ujfalusi@linux.intel.com>,
Richard Fitzgerald <Richard.Fitzgerald@cirrus.com>
Subject: Re: [PATCH 2/2] soundwire: Intel: stop sdw clock in system suspend
Date: Wed, 1 Jul 2026 16:09:32 +0200 [thread overview]
Message-ID: <ddc5fd9b-84ae-4180-a470-679d5cc3d629@linux.dev> (raw)
In-Reply-To: <f895956a-a5fb-4b52-813c-110dfce8549d@opensource.cirrus.com>
On 7/1/26 14:15, Richard Fitzgerald wrote:
> On 01/07/2026 12:55 pm, Pierre-Louis Bossart wrote:
>>
>>> If the Manager doesn't send a clock-stop, the peripherals don't get a
>>> notification that they can enter a lower-power mode. The clock suddenly
>>> disappears without warning and without the peripherals being notified
>>> why, so they don't have any information to know what is happening.
>>
>> that's not quite right, see below.
>>
>>> The Manager should send a clock-stop notification before stopping the
>>> clock.
>>
>> That's exactly the existing logic in drivers/soundwire/bus.c, the core does notify all peripheral drivers of a clock stop transition.
>>
>
> It's been observed with logic analyzer captures on real hardware
> that the clock stop is only being sent in runtime suspends, not
> system suspends.
That's the expected behavior.
> Because of this, if the bus was in a runtime-resumed state when
> system suspend started the clock would stop without warning.
>
> Bard - that's the observed behavior this patch is fixing, right?
I think you are confusing 'clock stop' and 'clock pause', this is a well-known confusion in SoundWire. See Section 8.1.2.2 Clock Pause in the 1.2.1 spec.
The clock stop mechanism refers to the ability to remove all transitions on the clock line, but restart the transitions when the data line is driven high for some time.
In other words, the "clock stop" used in pm_runtime suspend will also arm a detector on the data line. That's the problematic part on the host, this detector cannot be kept alive in system suspend since it has standby power implications.
In addition, on Intel platforms, there's a well-known issue where you cannot remove power to the SoundWire IP while this wake detector is active. That's the reason why we introduced a pm_runtime resume before the system suspend, the transition from pm_runtime suspended to system suspended is not supported. see intel_pm_prepare().
the 'clock pause' is what you see with a logic analyzer, it's not the same as the full blown 'clock stop' mechanism because there is no handshake to prepare the wake, and no support for the detector. There is indeed no signaling or known timing on when this pause occurs in the system suspend phase.
But again such signaling is not required: if you want to enter a lower power mode prior to system suspend, you can do so in your peripheral driver. You do not need to know if/when the clock will be paused. Just add the relevant programming sequence before the device transitions to system suspend.
next prev parent reply other threads:[~2026-07-01 14:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 14:44 [PATCH 0/2] soundwire: bus: re-enable CLOCK_STOP_MODE1 support Bard Liao
2026-06-29 14:44 ` [PATCH 1/2] soundwire: bus: add CLOCK_STOP_MODE1 support back Bard Liao
2026-06-30 9:42 ` Pierre-Louis Bossart
2026-06-29 14:44 ` [PATCH 2/2] soundwire: Intel: stop sdw clock in system suspend Bard Liao
2026-06-30 9:33 ` Pierre-Louis Bossart
2026-06-30 10:35 ` Liao, Bard
2026-06-30 10:51 ` Richard Fitzgerald
2026-06-30 12:36 ` Pierre-Louis Bossart
2026-06-30 12:50 ` Richard Fitzgerald
2026-07-01 11:55 ` Pierre-Louis Bossart
2026-07-01 12:00 ` Pierre-Louis Bossart
2026-07-01 12:30 ` Liao, Bard
2026-07-01 12:36 ` Richard Fitzgerald
2026-07-01 12:15 ` Richard Fitzgerald
2026-07-01 14:09 ` Pierre-Louis Bossart [this message]
2026-07-01 14:59 ` Richard Fitzgerald
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=ddc5fd9b-84ae-4180-a470-679d5cc3d629@linux.dev \
--to=pierre-louis.bossart@linux.dev \
--cc=Richard.Fitzgerald@cirrus.com \
--cc=bard.liao@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=peter.ujfalusi@linux.intel.com \
--cc=rf@opensource.cirrus.com \
--cc=vinod.koul@linaro.org \
--cc=vkoul@kernel.org \
--cc=yung-chuan.liao@linux.intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox