From patchwork Wed Aug 26 03:48:35 2026 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chris Chiu X-Patchwork-Id: 2292341 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=185.125.189.65; helo=lists.ubuntu.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=patchwork.ozlabs.org) Received: from lists.ubuntu.com (lists.ubuntu.com [185.125.189.65]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4hV9d05L42z1xxf for ; Wed, 26 Aug 2026 13:49:24 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=lists.ubuntu.com) by lists.ubuntu.com with esmtp (Exim 4.86_2) (envelope-from ) id 1wz4da-0002OV-88; Wed, 26 Aug 2026 03:49:18 +0000 Received: from smtp-relay-internal-0.internal ([10.131.114.225] helo=smtp-relay-internal-0.canonical.com) by lists.ubuntu.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1wz4dX-0002K9-1D for kernel-team@lists.ubuntu.com; Wed, 26 Aug 2026 03:49:15 +0000 Received: from mail-yw1-f200.google.com (mail-yw1-f200.google.com [209.85.128.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id DCD913F342 for ; Wed, 26 Aug 2026 03:49:14 +0000 (UTC) Received: by mail-yw1-f200.google.com with SMTP id 00721157ae682-822ce245c5aso15644867b3.1 for ; Tue, 25 Aug 2026 20:49:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787716154; x=1788320954; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to:content-type; bh=FN/uqs2xoEzfJHSj1G1XfJmP7xAvluF/gYs0O5NVIeg=; b=hploFJqfIZ/lib/4Ht2fi6SyAVppVwUPmPwW/QO6bwDq8z4H6mB8OehzQAegL3KlXL /fKjOVxh4HD6+EDTANq3itgxONR+ZutuNGAGtShj758nEwN00eEFI37RorbAGoaajqBc hrEm8YzYKQbWUAnRLIPjtjN8of3V6IxPD3aVGUykOWhFiAnfv1yJ48PgnTbnvRWV8XpK BGG6UVmvMEaqvPuH7UxhPqZjjEGwxgLUfkXz/QrYf/7gg1dNsr+lOefC2E1+y7h/6GgV ulzhFioDMzeonu3L9Jqu4/DWegx/rLiaxPncD46xV2z6qW0Mevlke/JnFgMfTToaCvt6 3fbA== X-Gm-Message-State: AFuF++m/P5U5ph+gORph+WYo63K5BMzpbTKf9Js4nvv0VpATJRLCPDvV Zymxkv95uazvuJPb3F4/1yViXmGNyDuZgqcJjuIZr/0pYDvQ9vEyGZeC9c3fbUPzKy4XkvTt+aH 2sV4vXO50vng4GHUHG2I9etGReynm/Faihh9164iVxtnh33sCvKqd8oDL8IzE6s/151qQz92Dc4 X81BDs3fe/wW0ELYk/ X-Gm-Gg: AR+sD11lKscAKeHhQAFdkWVPt5F6Ul7zMYnXwmIxbMn++paU0agiOGYuW1mOO9pDSG7 xzb38hE0HjsDFyE5Bt+RdQ5W45HnnPzjAxWBpZe5ZKVreqHwyYOOqAGtJ2fkYzQeiaiAV2BT9AN eU9qLx4nwMB2JrRugMBEDYokqz6KmofpjljmpH8ijfv+RSOv/xmdD0zOVfn8RLJneW87eoPcP5+ Y5MWLdtTem54GQNyhkUPZTok7Gl6qOXxnYev9iOGILM+eWUPxEOfkENJrN+oZ70A4A/taZ2f2/v 62d+e1zd7diDg93qD0g9cc6TFLROypAsIeRz2Rv43t8InPBwL62g4joal7QaLdIwyoVDv5eGmyA Bqm7oCheClg== X-Received: by 2002:a05:690c:6e83:b0:854:4ed4:c1b4 with SMTP id 00721157ae682-857477a3744mr16806557b3.18.1787716153708; Tue, 25 Aug 2026 20:49:13 -0700 (PDT) X-Received: by 2002:a05:690c:6e83:b0:854:4ed4:c1b4 with SMTP id 00721157ae682-857477a3744mr16806417b3.18.1787716153224; Tue, 25 Aug 2026 20:49:13 -0700 (PDT) Received: from localhost.localdomain ([2001:67c:1560:8007::aac:c1a2]) by smtp.gmail.com with ESMTPSA id 00721157ae682-8570cd697f4sm9679887b3.33.2026.08.25.20.49.11 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Aug 2026 20:49:12 -0700 (PDT) To: kernel-team@lists.ubuntu.com Subject: [SRU][R][PATCH v2 5/5] ASoC: tas2783-sdw: drop stale regcache on uninitialized re-attach Date: Wed, 26 Aug 2026 11:48:35 +0800 Message-ID: <20260826034835.661988-6-chris.chiu@canonical.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260826034835.661988-1-chris.chiu@canonical.com> References: <20260826034835.661988-1-chris.chiu@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Chris Chiu via kernel-team From: Chris Chiu Reply-To: Chris Chiu Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Andrey Golovko BugLink: https://bugs.launchpad.net/bugs/2164967 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 writes the device's TAS2783_SW_RESET register - a vendor register write that clears the device's register file and DSP state, not a SoundWire reset, so no re-enumeration is involved - and re-downloads the firmware. Before doing any of that, it syncs back a register cache that still holds the pre-suspend values. That sync is useless, since the 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. Reordering the sync after tas_io_init() and marking the cache dirty is not a workable alternative here: tas_regmap has no .writeable_reg, so the cache accepts every register up to .max_register, including ones for which tas2783_sdca_mbq_size() returns 0. regmap_sdw_mbq_size() rejects those with -EINVAL, so the replay fails on the first such register 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 Link: https://patch.msgid.link/3e2751d1fb027bed0f09c88e5e56da8f@gmail.com Signed-off-by: Mark Brown (cherry picked from commit b627da43035744ca4d691fbf56eef60268319873 linux-next) Signed-off-by: Chris Chiu --- 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 5c6866f3d3b5..adeb01ac805e 100644 --- a/sound/soc/codecs/tas2783-sdw.c +++ b/sound/soc/codecs/tas2783-sdw.c @@ -1189,7 +1189,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" : @@ -1205,14 +1204,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 + * resets the device via TAS2783_SW_RESET 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. Syncing after the reset is not an option either: + * the cache accepts registers for which tas2783_sdca_mbq_size() + * returns 0, and writing those back fails with -EINVAL. + */ + regcache_drop_region(tas_dev->regmap, 0, UINT_MAX); /* perform I/O transfers required for Slave initialization */ return tas_io_init(&slave->dev, slave);