From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) (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 5AE7D4A33 for ; Mon, 27 Jul 2026 08:35:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785141340; cv=none; b=Ffw6sqXXS0m6J3YARF9MQOdfMr17Yg03iAh9V4R9VdeVuzy34gG+uZY98C+CXZq1zOxwbKpAgJb1DWdq3aPz5I8extSyJUtSgXsN+xEEGVKglaKpBoFMRe40fnw69NYVya3j8jmGNTTPHVgT9v/i22jY14kUaIs8OdRZzABIkoY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785141340; c=relaxed/simple; bh=bA7oj9ccwe6Kzir9n2mqdfKZfY2btLBru5dHxfW1sgk=; h=Date:Message-ID:From:Subject:To:Cc; b=KoSq+F4J4R0P8DgDaVFLoIlMOyUaQF3v2ZO3psNdFkPjVQbsI3MTGiwDNRkoMNS/20IeabdyG2/LiyWcRpjR8iY5MG3d7qv6QJ/27LxGDwy5C4AGyC4RxN8Xirs4ANhsN7tO3E3T26gkstGn+ysRiioZrMB0nZJlYRzttvBwbq4= 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=gugzACQU; arc=none smtp.client-ip=209.85.167.53 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="gugzACQU" Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-5aec201b582so2508852e87.1 for ; Mon, 27 Jul 2026 01:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785141337; x=1785746137; darn=vger.kernel.org; h=cc:to:subject:from:message-id:date:from:to:cc:subject:date :message-id:reply-to:content-type; bh=x/gkkUAnrF/aaJnhoiRj8xjicaVMcuIpBr9vNF3q7Mk=; b=gugzACQUQ28zrEOgz8bkk94nfxDyW+8rDqRtNKy+d9vL+EWxlH7A0a8C8q45xf1xQ4 s/MfPiyQbPFJpKPiwnQfwpUQBaQlQHdsS/UTIoZtrVR9rgHfwH6LA4UarlYl9O67yz3R OiERYT/7ofluOWicTl/ejlxRiN/Bpg5Q2uL4thdQFiJRDGbI/4oWitj7UPifJnD8sCI2 VCtOV5tuZY6soOmgb5apvjou0ZuEkREBkWOT25krD8fpHUyroF0xYPCLcqXzWM6G6kvR ra6i32gb1lDiSeNEI+h7RW5U0+zh3pMGxaiOMt739r+Cne3ShdZcj3Y7X0WYO/pw7z+K DSPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785141337; x=1785746137; h=cc:to:subject:from:message-id:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=x/gkkUAnrF/aaJnhoiRj8xjicaVMcuIpBr9vNF3q7Mk=; b=fQVFvMDwWuegpbNz//sAS5WHoqL8e+541qMTMjg/CGTN9vPzoXe7XxBLiaQdzzBe3M 5aqEn2BlHpzIoETEANY7APdn6L3ZxdLvU3rcvN3D3Myy+ut7TTz5CnwqcR7KNn0PrgLT Qxxr4qr/WUiInqZLZJe4eRYZbIhsZOSaR1uuVQQ6hoeYjV8do8e45XOf0ys33SR5Fsr0 WzA3L7O2eIZM4/HXpeQHC1a+aJFQdrz8T865sE0U19oRm4EAhW73udnM0kwTkhGg/XMw zpf4oZfVfwOVjbfOhDu4hScnkMetTl1GmwcF4ADfzJY3nOF0U9RiiYYzZtzC5ssq+aF+ Y0SA== X-Forwarded-Encrypted: i=1; AHgh+RpQQ3J8U9E10s21OlILB27sYylnMsqnBhGRqiXgcPtGkFov8MKQCWP0wNwbkOGz/V7rZH+t/0nDSCr/cTg=@vger.kernel.org X-Gm-Message-State: AOJu0YxAwDBYTzrFVXwl5T9/7ByFS1mKqTpmp+qRe0S0s4P1Xai5X4Sb 1ZsFRacE/t8aIzrN7mZKZ+MgUu0oVioyrmySjYJdanI8ykVF3UZcUO+N X-Gm-Gg: AR+sD10L3pjq7+6o5RpQ/5fzqAFnN2A6YccmJHZUNAPazBZkUvVK0nzeZCh3FV2D/j+ EB8InFwGYbXU8XxRnHBDJ6ORDcjnKGiBjR1QFNb8ZJuGktZif6aClHe0evXBqPi/tKgb9qSG3hB P98gqAvofLnLj/88f9m7cKQRmD5TjTPe2AEGcnvvKm0AqhOaruPHWYpbosKZ93IXWDM3QzhGVqZ wiu8hjYMTR/2hPVhcu5tZzQDaT9n0SeZgE52Ye2xRdf9hfhUWfYQkyGdff2qhGJFPZaI00WCKoh mUw8/W0VZ61yMB4w4xRZwy/KZ7k4vNTrgJ/PWVC/Xwcjtr5Sk6nb9OW2AYLk3iBObdjWdP1ZFD6 /p5cKoXEYIcL7hMvhwXhc6kM0b/uTKfW6E51Z9UnKN4ck+X1YHCC6rYz1OllVtcXd2y/RgcBAqy s= X-Received: by 2002:a05:6512:ad4:b0:5b2:a397:734 with SMTP id 2adb3069b0e04-5b2c1b6af37mr1779897e87.53.1785141337125; Mon, 27 Jul 2026 01:35:37 -0700 (PDT) Received: from localhost ([5.227.22.1]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5b2be089e8fsm1278968e87.32.2026.07.27.01.35.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Jul 2026 01:35:36 -0700 (PDT) Date: Mon, 27 Jul 2026 11:35:34 +0300 Message-ID: From: Andrey Golovko Subject: [PATCH] ASoC: tas2783-sdw: drop stale regcache on uninitialized re-attach To: Shenghao Ding , Kevin Lu , Baojun Xu , Sen Wang , Liam Girdwood , Mark Brown Cc: Jaroslav Kysela , Takashi Iwai , Antoine Monnet , Pengpeng Hou , linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: When the peripheral re-attaches after the SoundWire controller was power-gated during system suspend (s2idle reaching S0i3 on AMD ACP), the amplifier has lost all of its register and DSP state. tas_update_status() handles that by re-running tas_io_init(), which soft-resets the device and re-downloads the firmware, but before doing so it syncs back a register cache that still holds the pre-suspend values. That sync is useless, since the soft reset immediately wipes whatever it wrote, and it leaves the cache claiming that the amplifier is already powered up and unmuted. Subsequent read-modify-write updates - DAPM amplifier power-up, SDCA PDE transitions at stream start - then see "no change" and skip the hardware write. Playback runs without a single error while the speakers stay silent. Unbinding and rebinding the driver restores audio, since probe starts from a fresh cache. Drop the cache instead of syncing it when an uninitialized device attaches, so that later accesses see the real hardware state. regcache_mark_dirty() + regcache_sync() is not an option here: the cache can also hold registers outside the SDCA MBQ map, written during the init sequence, which the MBQ backend refuses to write back. The sync then fails with -EINVAL and takes initialization down with it. Cached user settings fall back to hardware defaults across such a power loss, which seems clearly preferable to a silent amplifier - the device is being reset and its firmware reloaded at this point anyway. Tested on an ASUS ProArt PX13 HN7306EAC (AMD Strix Halo, ACP7.0, two TAS2783 amplifiers plus RT721 on SoundWire link 1): the speakers work after an s2idle resume with ~51 s of S0i3 residency, where previously they stayed silent despite a complete firmware re-download. Fixes: 4cc9bd8d7b32 ("ASoc: tas2783A: Add soundwire based codec driver") Reported-by: Antoine Monnet Closes: https://lore.kernel.org/all/c66ae00a-e878-4af0-a05a-272e9574eaa5@montane.tech/ Signed-off-by: Andrey Golovko --- Based on broonie/sound for-next (asoc-next), i.e. on top of 0d6b2d6f93a6 ("ASoC: codecs: tas2783-sdw: Propagate regcache_sync() errors"), which touches the same call site. Tested on 7.2-rc4 plus the ACP MSI-on-resume fix 5893013efabb, which is a prerequisite for the peripherals to re-attach at all on this board: https://lore.kernel.org/all/466a905d-8203-46d2-bfe4-a3b3f9b5d68b@montane.tech/ sound/soc/codecs/tas2783-sdw.c | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/sound/soc/codecs/tas2783-sdw.c b/sound/soc/codecs/tas2783-sdw.c index db58c50e8a83..e62470671951 100644 --- a/sound/soc/codecs/tas2783-sdw.c +++ b/sound/soc/codecs/tas2783-sdw.c @@ -1216,7 +1216,6 @@ static s32 tas_update_status(struct sdw_slave *slave, { struct tas2783_prv *tas_dev = dev_get_drvdata(&slave->dev); struct device *dev = &slave->dev; - int ret; dev_dbg(dev, "Peripheral status = %s", status == SDW_SLAVE_UNATTACHED ? "unattached" : @@ -1232,14 +1231,23 @@ static s32 tas_update_status(struct sdw_slave *slave, if (tas_dev->hw_init || tas_dev->status != SDW_SLAVE_ATTACHED) return 0; - /* updated the cache data to device */ regcache_cache_only(tas_dev->regmap, false); - ret = regcache_sync(tas_dev->regmap); - if (ret) { - regcache_cache_only(tas_dev->regmap, true); - regcache_mark_dirty(tas_dev->regmap); - return ret; - } + + /* + * The device is attaching uninitialized: either this is the first + * attach, or it lost power (and with it all register and DSP state) + * while the controller was power-gated during system suspend. The + * cache still holds the pre-suspend values, and tas_io_init() below + * soft-resets the device anyway, so syncing it back is both useless + * and harmful: later read-modify-write updates would compare against + * stale data and skip the hardware write. + * + * Drop the cache instead, so that subsequent accesses see the real + * hardware state. regcache_mark_dirty() + regcache_sync() cannot be + * used here: the cache may hold registers outside the SDCA MBQ map, + * which the MBQ backend refuses to write back. + */ + regcache_drop_region(tas_dev->regmap, 0, UINT_MAX); /* perform I/O transfers required for Slave initialization */ return tas_io_init(&slave->dev, slave); -- 2.53.0