public inbox for linux-sound@vger.kernel.org
 help / color / mirror / Atom feed
From: "Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>
To: Cole Leavitt <cole@unwrap.rs>,
	Bard Liao <yung-chuan.liao@linux.intel.com>,
	Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Daniel Baluta <daniel.baluta@nxp.com>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>,
	Kai Vehmanen <kai.vehmanen@linux.intel.com>,
	Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>,
	Takashi Iwai <tiwai@suse.com>,
	sound-open-firmware@alsa-project.org,
	linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] ASoC: SOF: Fix IPC reliability and post-resume SoundWire init
Date: Mon, 16 Feb 2026 18:41:36 +0200	[thread overview]
Message-ID: <cc238c2b-1a76-4da1-86ae-8accf235f265@linux.intel.com> (raw)
In-Reply-To: <20260214064054.19961-1-cole@unwrap.rs>

Hi Cole,

On 14/02/2026 08:40, Cole Leavitt wrote:
> Two fixes for SOF IPC4 reliability issues observed on Lenovo ThinkPad
> P16 Gen 3 (Arrow Lake-S, CS42L43 + CS35L56 over SoundWire):
> 
> 1. Replace the broken delayed_ipc_tx_msg mechanism with a bounded retry
>    loop. The old deferred dispatch silently drops messages during D0i3
>    transitions, causing 500ms+ hangs per IPC chunk.
> 
> 2. Add a platform ops callback (dai_link_hw_ready) so Intel HDA
>    platforms can wait for SoundWire slave initialization before ALH
>    copier setup. Without this, the DSP enters an unrecoverable wedged
>    state when userspace opens a PCM before slaves finish re-enumerating
>    after resume.
> 
> Tested on ThinkPad P16 Gen 3 with repeated suspend/resume cycles
> and concurrent audio playback.

This issue is a new one for us and we would like to understand what is
going on, can you create an issue at
https://github.com/thesofproject/linux/issues

and include the full kernel log with sof-dyndbg.conf in place like asked
in this comment:
https://github.com/thesofproject/linux/issues/5517#issuecomment-3233283263

with kernel (Most likely 6.19 based on the base-commit), sof-firmware
and alsa-info.sh output version as well?

In the second patch you are pointing to fw boot timeout issues, which
makes me wonder what is going on.
It is possible that the codec drivers prevent the DSP power off and on
next boot we obviously fail to receive the FW_READY since the DSP and
firmware is in booted state already.

thank you for the help!

> Cole Leavitt (2):
>   ASoC: SOF: Replace IPC TX busy deferral with bounded retry
>   ASoC: SOF: Add platform ops callback for DAI link hardware readiness
> 
>  sound/soc/sof/intel/cnl.c            | 17 ++---------
>  sound/soc/sof/intel/hda-common-ops.c |  1 +
>  sound/soc/sof/intel/hda-ipc.c        | 17 ++---------
>  sound/soc/sof/intel/hda.c            | 44 ++++++++++++++++++++++++++++
>  sound/soc/sof/intel/hda.h            | 14 ++++-----
>  sound/soc/sof/intel/mtl.c            | 17 ++---------
>  sound/soc/sof/ipc4-topology.c        |  8 +++++
>  sound/soc/sof/ipc4.c                 | 17 +++++++++--
>  sound/soc/sof/sof-priv.h             |  3 ++
>  9 files changed, 83 insertions(+), 55 deletions(-)
> 
> 
> base-commit: 2687c848e57820651b9f69d30c4710f4219f7dbf

-- 
Péter


      parent reply	other threads:[~2026-02-16 16:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-14  6:40 [PATCH 0/2] ASoC: SOF: Fix IPC reliability and post-resume SoundWire init Cole Leavitt
2026-02-14  6:40 ` [PATCH 1/2] ASoC: SOF: Replace IPC TX busy deferral with bounded retry Cole Leavitt
2026-02-16 12:39   ` Péter Ujfalusi
2026-02-17 21:49     ` [PATCH v2] " Cole Leavitt
2026-02-19  7:11       ` Péter Ujfalusi
2026-02-14  6:40 ` [PATCH 2/2] ASoC: SOF: Add platform ops callback for DAI link hardware readiness Cole Leavitt
2026-02-17  8:08   ` Pierre-Louis Bossart
2026-02-16 10:52 ` [PATCH 0/2] ASoC: SOF: Fix IPC reliability and post-resume SoundWire init Péter Ujfalusi
2026-02-16 16:41 ` Péter Ujfalusi [this message]

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=cc238c2b-1a76-4da1-86ae-8accf235f265@linux.intel.com \
    --to=peter.ujfalusi@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=cole@unwrap.rs \
    --cc=daniel.baluta@nxp.com \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=pierre-louis.bossart@linux.dev \
    --cc=ranjani.sridharan@linux.intel.com \
    --cc=sound-open-firmware@alsa-project.org \
    --cc=tiwai@suse.com \
    --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