From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) (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 7A170495510 for ; Thu, 13 Aug 2026 16:32:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786638756; cv=none; b=WLo0N2lbm0ufBZlylnQICpWBRe356jbXBbgcHjg91Cms7GlKcmnfLQQf1ZW32hpnObESocLplsCBmrwRFx87FPi+H+4i3wsdsDjyYl5MAftghkczCabChJbTZ6LvPhJr46tySAttBLFELUXybucWYjA+QKSG7fIabigkukqMrPU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786638756; c=relaxed/simple; bh=yZsayIIRWkvLHibdEjd2G21zSgUhMa0Xp79RehKKOIU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ZN3SYztaaggK6HJnzQOqm52lPQw2G/gLHtt4klzP+FGjgjY61kNcMymRhbZPHMBZRQv1iHCifAB7ep8AVy8I8/3qR4W+n1T2GUbVBmFPxsi0bvf/vGJPlnTkdST1GA1VDUekV9ZBIzh0jjx0vRa3tHeJY4iTUAEJUVM6i4eCya8= 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=T06hmwl5; arc=none smtp.client-ip=209.85.167.54 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="T06hmwl5" Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-5b2aab18795so977898e87.2 for ; Thu, 13 Aug 2026 09:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786638751; x=1787243551; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=BUYf9Zsf2WSHXbVUW7L/pdubtMVZe2GVng4+E2hHXS4=; b=T06hmwl5Bu2thEL2vt9Rm7T5JVg/YY4369X+ZUIRMo61BqHqIuJoFuRd3dKcZirbR/ FrmfvI3pFjjweWOTFo3ov/yjlaGKKHhu4pivflIPQgvVKWn3M9RN4r/UYGzJaG/ThNBv rZrLVY15J32oKXGehIXkGNmK286Tnj0Tnz2XhWJwWjswFmAmBSCau0uAAc/ci7NZf/FS yt0dv9llSejp3E8NvUxEHd04KQkdciIVGbg2YN5fCKHhPXM7TsxGkZlq/u9Q8xoHkWs7 HIG9wO2WbgxXn1l9OqcUtUgofk3xIZyDlajlAMZGvprtAk65IifU56ZK5CMW6H7f+K2n eovQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786638751; x=1787243551; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=BUYf9Zsf2WSHXbVUW7L/pdubtMVZe2GVng4+E2hHXS4=; b=QbYXUmuR91FbIuJ5atYC+QVQF2zk/dh4XFLgtagEyuabRBzhQUEwar/2ZcyypMtkCf /nvC73yBMmED3p5ek1qkAjsF84hG+cWrrrES8TXoOzFQWMlfa7cuoKmriTK1Qu/+oQdd uirtchuOk4krxkorGdXIkWUvyOomJS2T0WL3imOE3aUSwIJmVKx/3Ram0NQEkriVQtdn Sb/1M+T+Pd0LYuJcDLhpKz6ZIJ2CEknjGpf/xGX2scNucYVWcxXzzpNF/tB0Q/of5wBl lh2nOBUBAEs6Ku2YkEI82VAjDfh+T9gLUezCO0OEmP5Lp4JnIhHyMeBH0B7QZhmTabuM epCQ== X-Forwarded-Encrypted: i=1; AHgh+Rq7Fj4I0oBYGqiKGC3p186ENpsGXf+JRGEPb96kEc/sg18BdeZAYgtzHHj4ubvv+0DlwxWSHG5LxdIXWTk=@vger.kernel.org X-Gm-Message-State: AOJu0YyxFBUngSZFGuAnPuqB2F03jCG10GHq3Cc8Kut2EZHQCbpezobd 8hjuDL5ApI7Di+8O4p4tsMP4KnR4J5I1NFvqbixlLJl7NULA/1WcyNWe X-Gm-Gg: AR+sD12ipdye5DwPqdgVDKg1vdfBBjfw2mSY3XJWLco75NYrybac9+j3LZkgszLNB28 6J3LJB5QLcL4AVP75znrp10JVIavfrjm6EP86v0rDyCBJyFq9DrOX0oMPiYCV2OmOAoTPt9JXi8 xWyfitheTq1QkSqrUCVzx0lMtvZrIzWNyElu5GAPnQuUfwMpCCd7Z7JUSOa3v4HCQpsza9xR2Bu wHR10CnIpfHZomN63Qt1znCwFG2N9QiZVofeu7TX2NCSNlJuUW8zObVTFYwpilPOct7VS7HZHah 3RMCBbHGArOSYLbzbv4kToqf6Qw/1X8ObWwlBb4lIwvhZvgrB78jdBLTtUILMTr+nmLEhVxkhLi 7qDDP8/HOnihjeJCWkMPUmIKZVqBA2hpiF25cBqj9fKiUcczUcOESlZ8gA27g/rmyBPStZn9cr0 P4PfGzZwFxCWLbHX3U/sd7uNklmvw8DmcO8BAet4XVmnQM+uw4NxFF+O3IK+4kuCOLaVYtXX/i5 zA6mNgJBudqtobDg/qrNWI= X-Received: by 2002:a05:6512:428a:b0:5b4:473f:847b with SMTP id 2adb3069b0e04-5b453f836d2mr1027163e87.39.1786638750711; Thu, 13 Aug 2026 09:32:30 -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-5b458b9a986sm1401e87.14.2026.08.13.09.32.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Aug 2026 09:32:29 -0700 (PDT) From: Andrey Golovko To: Mark Brown Cc: "Mukunda,Vijendar" , Robin Everaars , Shenghao Ding , Kevin Lu , Baojun Xu , Sen Wang , Liam Girdwood , Jaroslav Kysela , Takashi Iwai , "Holalu Yogendra, Niranjan" , Pierre-Louis Bossart , "Dommati, Sunil-kumar" , Antoine Monnet , Ville Saarinen , linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ASoC: tas2783-sdw: power the Function up before preparing the port Date: Thu, 13 Aug 2026 19:45:00 +0300 Message-ID: <20260813194500.10598-1-andrey.golovko@gmail.com> In-Reply-To: <213117c2-02d0-4e94-be2f-c172ebedcfe4@sirena.org.uk> References: <20260813001500.9218-1-andrey.golovko@gmail.com> <213117c2-02d0-4e94-be2f-c172ebedcfe4@sirena.org.uk> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Thu, Aug 13, 2026 at 02:22:52PM +0100, Mark Brown wrote: > Does this DTRT if userspace restartss the stream by directly calling > SNDRV_PCM_IOCTL_RESUME (AMD adverise SNDR_PCM_INFO_RESUME...)? No, it does not. I wrote a test that takes that path deliberately - it plays a 440/660 Hz tone straight to the hw device and, when the write returns -ESTRPIPE, calls snd_pcm_resume() and never snd_pcm_prepare() - and on this machine, with v1 applied: before suspend after snd_pcm_resume() DP1 PrepareCtrl 0x1 / 0x2 0x0 / 0x0 PDE23 req / act 0x0 / 0x0 0x3 / 0x3 tone 440 / 660 Hz +65.5 / +75.2 dB -1.7 / +1.8 dB (two amplifiers on the link, tone measured through the internal microphone against the noise floor of the same run). snd_pcm_resume() returned 0, the PCM stayed RUNNING and nothing logged an error; the ports were simply never prepared again, so the callback v1 hooks was never reached. asoc_sdw_trigger() only calls sdw_enable_stream() on SNDRV_PCM_TRIGGER_RESUME, and the channels are then enabled on ports that no longer exist as far as the peripheral is concerned. v2 preparing the stream on that trigger fixes it: before suspend after snd_pcm_resume() DP1 PrepareCtrl 0x1 / 0x2 0x1 / 0x2 PDE23 req / act 0x0 / 0x0 0x0 / 0x0 tone 440 / 660 Hz +73.7 / +88.3 dB +73.7 / +88.5 dB It is on the list as [PATCH v2 0/2] ASoC: tas2783: prepare the port again on the resume path Message-ID: <20260813194000.10412-1-andrey.golovko@gmail.com> > Similarly we can suspend while prepared. That one I could not close, and I do not think it can be closed from either the machine driver or the codec. A stream suspended while merely PREPARED gets no trigger at all: snd_pcm_do_suspend() returns early when the stream is not running, and snd_pcm_do_resume() returns early unless the suspended state was RUNNING or DRAINING. Userspace calls snd_pcm_start(), the ports are enabled, and nothing in the path knows the peripheral came back empty. sdw_prepare_stream() cannot help either: the SoundWire stream is still SDW_STREAM_PREPARED, which it treats as "nothing to do" by design. What does know is the bus - the peripheral goes UNATTACHED and comes back uninitialized. Invalidating the prepared state of the streams that peripheral takes part in looks like the right place to me. That is a core change; tell me if you want it as part of this series and I will write it. Vijendar, thanks - that matches what the measurement says, and v2 takes the first of the two options you named. Robin, your negative result for v1 earlier today is consistent with all of this: playback opening cleanly, both amplifiers attached and silent is exactly what this path looks like from userspace. Two things worth checking on your side before you spend another cycle: - whether your player recovers with snd_pcm_resume() rather than snd_pcm_prepare(). If it does, v1 alone could never have worked for you, and v2 is the patch to test; - v7.1.7 predates b627da430357 ("ASoC: tas2783-sdw: drop stale regcache on uninitialized re-attach"), which is in for-7.3. Without it the register writes made on resume can be dropped by the cache, which is a second reason a v7.1.7 test says less than a for-next one. I would take you up on the offer of registers around a failed playback, but on a for-next kernel with v2 applied. The register readout above comes from a small out-of-tree module that reads DPn_PrepareCtrl, DPn_PrepareStatus, ChannelEn and PDE23 over the bus without touching the regmap cache; I am happy to send it to you off-list if that helps. Thanks, Andrey