Linux Sound subsystem development
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
To: Antoine Monnet <antoine@montane.tech>, linux-sound@vger.kernel.org
Cc: Vijendar Mukunda <Vijendar.Mukunda@amd.com>,
	Vinod Koul <vkoul@kernel.org>,
	Bard Liao <yung-chuan.liao@linux.intel.com>,
	Mark Brown <broonie@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Shenghao Ding <shenghao-ding@ti.com>,
	linux-kernel@vger.kernel.org
Subject: Re: SoundWire: amd: all peripherals stay UNATTACHED after s2idle resume (AMD ACP70, ASUS ProArt PX13 HN7306)
Date: Mon, 20 Jul 2026 21:30:09 +0200	[thread overview]
Message-ID: <ad18e774-3478-4a7a-8b29-86564f77ad35@linux.dev> (raw)
In-Reply-To: <466a905d-8203-46d2-bfe4-a3b3f9b5d68b@montane.tech>


> One further detail looks suspicious, though I have not confirmed it is the
> cause: in the POWER_OFF_MODE branch of amd_resume_runtime(), the clock
> resume
> handshake is conditional —
> 
> val = readl(amd_manager->mmio + ACP_SW_CLK_RESUME_CTRL);
> if (val) {
> val |= AMD_SDW_CLK_RESUME_REQ;
> ...poll for AMD_SDW_CLK_RESUME_DONE...
> if (val & AMD_SDW_CLK_RESUME_DONE) {
> writel(0, ...);
> amd_manager->clk_stopped = false;
> }
> }
> 
> After amd_deinit_sdw_manager() and a D3 transition the register block
> may well
> read back as 0, in which case AMD_SDW_CLK_RESUME_REQ is never issued and
> amd_manager->clk_stopped stays true from suspend. Whether the peripherals
> require that clock-resume handshake before they will re-attach is a
> question for
> someone with the ACP70 programming documentation.

Even without the ACP70 documentation, if the clock line doesn't toggle
nothing will happen on the peripheral sides. That's a generic SoundWire
property, the peripherals can only look for a sync pattern on the data
line if there's a clock signal.

I don't have any specific info on this IP, in general such bugs result
from one of:
- manager IP not powered
- manager IO pins not configured for SoundWire operation
- clock not toggling
- reset sequence not applied

  reply	other threads:[~2026-07-20 19:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20 15:32 SoundWire: amd: all peripherals stay UNATTACHED after s2idle resume (AMD ACP70, ASUS ProArt PX13 HN7306) Antoine Monnet
2026-07-20 19:30 ` Pierre-Louis Bossart [this message]
2026-07-27  8:12 ` Andrey Golovko
2026-07-27 15:21   ` Mario Limonciello

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=ad18e774-3478-4a7a-8b29-86564f77ad35@linux.dev \
    --to=pierre-louis.bossart@linux.dev \
    --cc=Vijendar.Mukunda@amd.com \
    --cc=antoine@montane.tech \
    --cc=broonie@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=shenghao-ding@ti.com \
    --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