From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0781E37D11C for ; Fri, 7 Aug 2026 05:21:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786080123; cv=none; b=dgAVtqH5HeY5pJq2YV3GV75LMnDTX1ZBMTfDm6ikxQSEbeono4mKmaxiGFG8zuIyiwpyDGHVseGqGDB+HqGNwwK3+52jZWYSqwvdaaOoymHfXkhk3dDYe9rWVr6k8CKtGHG4j3oZvZ30ntSuFN9dRf2o8vpHkow0IOc9UeeT0Gc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786080123; c=relaxed/simple; bh=HSsBXFdUlIkuLwDWXwFFmBArCNAuG0DA46z3FbZjrlw=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: Content-Type:MIME-Version; b=sbxvFy62JmkLtIhPh5pnJ0796noFKBffGqfj/Th/Zb2aSPtwnUuZ36c6fRZP+etpMx5Og7kkdhzeiiLmdmfVjyWq7qCNNNtswNCPq6rwRxQrBSgRCjrACRnqHBouKHoyTO9ABZv0CmNcqBx4fzVrAk+VxksAM2FHSfSMcBxCpGg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=R6/wgH4Z; arc=none smtp.client-ip=209.85.167.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="R6/wgH4Z" Received: by mail-lf1-f51.google.com with SMTP id 2adb3069b0e04-5b0117dda13so2515847e87.0 for ; Thu, 06 Aug 2026 22:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786080118; x=1786684918; darn=vger.kernel.org; h=mime-version:content-transfer-encoding:content-type:references :in-reply-to:subject:cc:to:from:message-id:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=HzF2xPvcNfQpLHHlELzmZnypVmdloPb8Ky9A6X90We0=; b=R6/wgH4Z5uegvMtzpKH/P6o3+CRUMKD91Agu6j7qkl180C6mzq4GczBkHvatkdrKcJ OPFaUP7lpqW3csLDkHGZLvm0HUGd01UeiNEjeqaW80WBVLgmBj8KDgbd6v2rNJYGszOM zJZZRMJGS8cRnkx3mb3n1iEXl0wfW2ZPem+93r3KF0ItPaTTHu8CTC4WyAzEnNJqv2mx VKRA3E7PjnAVYYi+D6fCpWVWASJ8o6brxcmu/9M+OscUvsPuPXFfvlBiCJLBzk4ZWiS6 qMeeOh5k0npPFqOe5z9nwEO056/dqJrWSDfgw+wuXwlW6EpiFsqOzE+uVKvVmc2nhFTY pqyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786080118; x=1786684918; h=mime-version:content-transfer-encoding:content-type:references :in-reply-to:subject:cc:to:from:message-id:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=HzF2xPvcNfQpLHHlELzmZnypVmdloPb8Ky9A6X90We0=; b=gdavhhC50QtqcaYGMKiaTSjk64mul+tA7oUsxbmZbemHPn3ajZ7CQt3qoeWW/uC3bW +s9j+FcVYcuFZ4hVfQyCZ6pscILkkFV939/6FhilQTKAK1Qi7E0sSWHZ3eALAjzkhuFW yx+l9Cjd0HMXH6D8ghDOFxiy1C9yXIGMaMITpxppC+WvZEJyPfO7YCgKDhQXgSO5UW8d 9/40Pp93Fa/sbpFgtvuSoA7xTuGV1NrGX3Rml7YYz+we9wFr5O71bazui1b2QDMSLKzy OYMDV7Pr+zprQ9ZeYz4zM9lPTvTb5qQZDXJ3/h4tib/QX2013nvoregimBQ+LRzjgCV/ Tj/w== X-Forwarded-Encrypted: i=1; AHgh+RqaFmtAE0CXtZ7qISz81ZZ6vmqkxmv857QIUlKClWQIVpB1QDE3MI5qzl9ek+kVfoMnAhJ1vzl9k2YD+UA=@vger.kernel.org X-Gm-Message-State: AOJu0YzD3wuGWbSOkFoPy31i0bQ2NDuqPPNxdtHcN6MKW63c6emq9R5g 9vZmYyr7ToMVmQ1KI+X78M3vXgJcgZmzxBZccACQuhcu2LU3oVDp55ze X-Gm-Gg: AR+sD10eKwMBXZK/35LnbWAYUP/lKaBSN+ze6LIklyASm6gZ7B9yQuftokEiGTV9iJv tlL3O2W7Yxb6gS+SO5xPpV3cyjiNnTFQShrqFy3sNKf8NNTMmK/+pV6LJPqUopIVEvyWYAZsZp3 buwsT0Jukb1mXLep5zY5OmgeNKSevbGE8sIoRjhhfEfBT7cxTzGzL0RcriGIkxJM5xwhPdbq2Cf M+ReED41eaW4tz8/Qq6FhopMU2lYcw2RKbgI3XDduFqn9zT9vVIyW3zm4YDRnY9OwcHE+XrUg21 q3Rmkj801nb8l1mwyS4KfRDt99IpZSC6ZsvxdftvPhCxDm2Wt5YPd6eppcEvA+tk8h3GRzJ1Li+ 7ErKOofkTewDuAFdsLU9AP2EKRjFWuQxdTFKh48AzcGXoez3e/MCZDcxxiFj/PG9eBZY2ooPz5V 0hrU9ArlCW95Cn+IgOAudNWEh7c6XkPPWNkMVuB/NC1nkaIAzN5cNjegmGS3frYkAgt/1ytSXDw AZq94TgWp8mc95KjwS9U2hiMDKb45Ugow== X-Received: by 2002:a05:6512:1291:b0:5ae:b78c:da1 with SMTP id 2adb3069b0e04-5b2f4cc9220mr2797658e87.28.1786080117504; Thu, 06 Aug 2026 22:21:57 -0700 (PDT) Received: from localhost (host-80-73-162-2.rev.as20985.net. [80.73.162.2]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5b3055dee58sm265223e87.46.2026.08.06.22.21.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 22:21:57 -0700 (PDT) Date: Fri, 07 Aug 2026 08:21:56 +0300 Message-ID: From: Andrey Golovko To: "Holalu Yogendra, Niranjan" , Pierre-Louis Bossart Cc: Shenghao Ding , Kevin Lu , Baojun Xu , Sen Wang , Mark Brown , Liam Girdwood , Vinod Koul , Bard Liao , Vijendar Mukunda , Mario Limonciello , Antoine Monnet , linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: ASoC: tas2783-sdw: port prepare never completes after S0i3, no audio and no error (AMD ACP7.0, ASUS ProArt PX13) In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Hi Niranjan, Pierre-Louis, thanks to both - answers and new data inline. Pierre-Louis wrote: > Just to be clear: are you referring to a scenario where audio playback > is on-going, the device does a system suspend during the audio playback > due to a user request, and on resume audio is supposed to restart > playing? Not necessarily on-going playback - that's the point that makes this hit ordinary users. PipeWire keeps the PCM substream open the whole session, so the substream survives the suspend regardless of whether anything was audibly playing. After resume, even a stream started *fresh* by an application plays into that surviving substream and is silent. The only way to get sound back is to force the substream through hw_free + hw_params (I cycle the card profile, which PipeWire translates into exactly that). So the reproduction is deterministic and needs no aplay-in-background race: boot, let PipeWire open the device, systemctl suspend for >= 1 min (enough for amd_pmc to report real S0i3 residency; without residency the bug does not reproduce), resume, start any playback. Silent every time here. > It could be that the use of the port_prep callback is restricted to the > initial stream setup. I am not sure if that stream callback is invoked a > second time after a suspend-resume cycle I can answer that with a trace rather than a guess, with one caveat: stock ps-sdw-dma.c advertises SNDRV_PCM_INFO_RESUME, so a plain resume takes TRIGGER_RESUME and skips the prepare path entirely - no stream callbacks at all. With a local patch dropping INFO_RESUME (so userspace does a full snd_pcm_prepare recovery), the resume-spanning ftrace shows the complete sequence running after resume: sdw_prepare_stream -> sdw_prep_deprep_slave_ports -> tas_port_prep() invoked again, 4 calls (2 amps x 2 callbacks), DPn_PrepareCtrl written with the right masks, then enable. So the callback *is* invoked on the recovery path - and the amps are still silent. The one thing that separates every silent case from every working case in my traces is the de-prepare: the working path (hw_free) writes DPn_PrepareCtrl = 0 first, then a fresh prepare writes 3. The silent path re-writes 3 over 3. After the device has lost power and been re-initialized (SW_RESET + firmware re-download on re-attach), a rewrite of the same value evidently does not re-arm anything; the 0 -> 3 edge does. Niranjan wrote: > The device expects the DPn_PrepareCtrl bits to be set to be functional - > but doesn't update DPn_PrepareStatus. Thanks, that explains the design - I'll withdraw the "port prepare never completes" framing then, since it leaned on reading DPn_PrepareStatus, and per your description those bits are not to be interpreted in Simplified_CP_SM. One empirical note, for what it's worth: on this hardware 0x104 is not static. Across all my dumps, on both amplifiers, it reads 0x3 in every silent state and 0x0 in every working state, tracking the audible state exactly. I'm not suggesting polling it - just that on this part the register does reflect something about the port state. Which leaves the practical question for TI: After the amplifier loses power while the manager is power-gated (attach as UNINITIALIZED, SW_RESET, firmware re-download), what does the device need before a port prepare takes effect again? Empirically writing DPn_PrepareCtrl = 0 and then 3 works, while writing 3 alone does not. If the 0 -> 3 sequence is genuinely required, where should it live - tas_port_prep() unconditionally de-preparing before preparing, or the codec driver de-preparing its ports as part of the re-attach re-init? If TI can confirm the required sequence I'm happy to write and test the patch on this hardware - I already have the register dumps and traces automated. Thanks, Andrey