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 5F3463E1230 for ; Mon, 27 Jul 2026 08:13: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=1785140017; cv=none; b=pLFrVvL1Dd+EQz8Enbjqpe8QxcPCFHgVyHMC1eJFoSZL6UHxesKQWwzM6KzU+yLCGDsMYskTiVrOtzHg4i8pxuLpwNLmKBYC0NPqXuaHDQ3xhnZqeIbxF7RVuk/7T9aJeff88bVfHQDOlrkyY9A01YPTVVR5+9FgmtDd8eFsemI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785140017; c=relaxed/simple; bh=4wmi0uwktBB60+gLClZTQrof539eNcHdK5yq44R5eMw=; h=Date:Message-ID:From:Subject:In-Reply-To:References:To:Cc; b=L/4eH+TICHYT1kGzMet4WKuUqcmOoxyikFik8I68AY8XQia0xCgvx8tuTG15AI+ugx3cVCGLYiuubLVxj0G9BbUEB5RM+X7VG1jylcTVjlClHUTSA17oq4oPkEDrsJn6GK8WM5aphnqZYsX/0w0EwIjMVDUqJes96N8FdOrVfck= 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=YmDV/Izo; 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="YmDV/Izo" Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-5b2a8e4c77eso1944559e87.1 for ; Mon, 27 Jul 2026 01:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785140011; x=1785744811; darn=vger.kernel.org; h=cc:to:references:in-reply-to:subject:from:message-id:date:from:to :cc:subject:date:message-id:reply-to:content-type; bh=oCmkrdJ0HThAc945hm7QlIO5Boe0tZp2HaWTyRug7BE=; b=YmDV/IzoodBvRngzuXH2h1kFQ6ivS6Jlj1oChy/soEIU/ZYYHnW3ldCoNDvFMUIHOq 3Npm8pBkTkJhqmlGNi14GOQgiDGyuBBRAAheD89iAWV8Hwv89iIjiz/VMz5Jo3iltVXG qmEw6+VbPVF1BfOiMIaXner9C8qvggaM4bONHAHkitt76R65hT3vFeDZ4Mw+aIMQB9VI qrHshoKDYufstkC1eXND4E1k3xY9htvtqOnx5Jxu/IxDAoWpgZIN4lx+MdEWCE+6DBFP VqhfXDSEkjdMOLmpax0XDG1ive6udfAZ/SvyBx/V37SwAl9F+z+vJJEBEnz0FKb8cNjd kDuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785140011; x=1785744811; h=cc:to:references:in-reply-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=oCmkrdJ0HThAc945hm7QlIO5Boe0tZp2HaWTyRug7BE=; b=dqcSGofXm4jXp5zQWBIR2l/KBXcvasU6jRtAXBu2k1OlsvAW0tqCtuS1KZLNwLakOL Ac2dDDU+D3LvHdAtlR2oOq7voPPa7M+KnhVr90DwO2vwd+sEX11rzt4gK7OPDCd310XW tR+A1n6bF9/CgXsJBwBHmCZJtYdbvrMEgDjnHZnt3+rK89wpIvPKgCEw1VSnMwIeAHsK N08TfWLBysSD0OU6uzkbd/SNoOhVob1AoPLp9lteBJETUsKzX8KYYsN3pc4hZg0bT3Hj fH2Ns7CP0Kt2Im5C8vT19MvWGJcIAvVKsDADVQsjhQT1O5iKrEiCgXnkAMiscC6LjWYw W23w== X-Forwarded-Encrypted: i=1; AHgh+Ro6sljYweMz/1MlN1x3pDF4iYNAEC7gReqYjmeKnerabKrZZYTXI24sUozFfgwui3HfbA3Gz0sPGO2Y8fw=@vger.kernel.org X-Gm-Message-State: AOJu0YwB3qmkzGDJ3NM6Nt8KPcJEuke+6dXdez4xIVMmQAkpaDUwxxe8 vS1k3+Q8k0pz8yyT4ZMf7jgyTLc75YQGQmBr46rCCmdgVOEiO7OQ/d1UnCvt1QMMQTJQfA== X-Gm-Gg: AR+sD13D5eW+2ZXD+LZgcup+1wWWGW0q2hV4dHH6L19xb8g675sPidwNOBbzGW4Xjwx hAWJhEHZ2P21n1BmOY6IOHHU6P5wwTUAUzRO3b0c9iqKbwJCXdU0B87aUz3SDLsiYZiJIjcP0iq rYafhSRgpOtUo2NN05gQGPBrw7tQXSgANkch9KVansvp69hTXP4dKIMOry1ZKc5nk88td42NKXA 9LWfSVXCP5ehXhuhT7vyhHBj83xzq8yov4r0iVo1f7Dw4QWOu+dSQLlugwAan8mX44dlZsHVLvj RCfQl01Ge4EbTjCj8nFu7Wswk7ijFnBwO3i/UqNMMGVO1rNcMkvhjD2o++FiELHyGfXgubz0x77 8nABzNthN0oAPj6mBwhGEnAY2HyjNBNWwe5p91pfi/2sLRUj47qEC8Fi+IoI83/1aeizCOkW01N c= X-Received: by 2002:a05:6512:2346:b0:5b0:1879:1ba5 with SMTP id 2adb3069b0e04-5b2c1b4fb9fmr1144363e87.58.1785140011140; Mon, 27 Jul 2026 01:13:31 -0700 (PDT) Received: from localhost ([5.227.22.1]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5b2be077b6asm1286549e87.15.2026.07.27.01.13.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Jul 2026 01:13:30 -0700 (PDT) Date: Mon, 27 Jul 2026 11:13:29 +0300 Message-ID: <2d59f17b67d3886a3085f0da8c8850f3@gmail.com> From: Andrey Golovko Subject: Re: ASoC: tas2783-sdw: calibration firmware not re-downloaded after s2idle resume (AMD ACP SoundWire, ASUS ProArt PX13) In-Reply-To: References: To: Antoine Monnet , linux-sound@vger.kernel.org Cc: shenghao-ding@ti.com, kevin-lu@ti.com, baojun.xu@ti.com, broonie@kernel.org, lgirdwood@gmail.com, Vijendar.Mukunda@amd.com, vkoul@kernel.org, yung-chuan.liao@linux.intel.com, pierre-louis.bossart@linux.dev, linux-kernel@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Hi Antoine, Same machine here (ASUS ProArt PX13 HN7306EAC, ACP rev 0x70, RT721 + 2x TAS2783 on link 1). First, the reason you never saw a re-download at all: on <= v7.2-rc3 the peripherals do not re-attach after s2idle, so tas_update_status() is never called with ATTACHED and nothing downstream of it can run. That is a separate ACP bug, fixed in v7.2-rc4 by 5893013efabb ("ASoC: amd: ps: disable MSI on resume in ACP PCI driver") Details in my reply on your other thread [1]. With that fix in place, the firmware IS re-downloaded on every resume and the one-shot ->hw_init gate is not the blocker: tas_update_status() sets hw_init = false on UNATTACHED, so the ATTACHED transition re-runs tas_io_init() and request_firmware_nowait() as intended. I confirmed the download really happens over the wire with ftrace: ~81k calls to amd_sdw_send_cmd_get_resp() during a single resume, i.e. an honest full re-download of both amps, not a cached no-op. One trap worth naming, since it fooled me for a while: in the resume path printk timestamps make the download look impossible (32 KB in ~150 us, 5 ns/byte), because sched_clock is not running yet that early. Do not trust the log deltas there - use ftrace. So the symptom you filed is real, but the mechanism is elsewhere. On this board, after a resume with genuine deep S0i3 residency (51 s of a 57 s sleep, per /sys/kernel/debug/amd_pmc/s0ix_stats), all three peripherals are Attached, the firmware is reloaded, every log line is clean - and the speakers are silent. Root cause #1: stale regmap cache --------------------------------- In tas_update_status(), on the UNATTACHED -> ATTACHED transition, the driver does: regcache_cache_only(tas_dev->regmap, false); regcache_sync(tas_dev->regmap); /* then */ return tas_io_init(&slave->dev, slave); Two problems: the sync runs *before* tas_io_init(), which performs a software reset and thus wipes whatever was just written; and there is no regcache_mark_dirty(), so the sync is close to a no-op to begin with. The cache therefore survives the power cycle claiming that the DAPM power/unmute bits and the SDCA PDE entity are already at their target values. Every subsequent regmap_update_bits() - amp power-up from DAPM, PDE programming at stream start - sees "no change" and skips the write. The amplifier stays powered down and nothing in the log complains. Consistent with that: unbind/rebind of slave-tas2783 (fresh cache) restores sound immediately, while toggling mixer controls does not. What does not work as a fix: adding regcache_mark_dirty() + a real regcache_sync() after tas_io_init(). This regmap is SDW-MBQ (devm_regmap_init_sdw_mbq_cfg) with per-register mbq_size, and the cache also holds non-MBQ registers written during init, so regcache_sync() fails with -EINVAL on the first such register, and the failure then also breaks probe ("Update Slave status failed: -22"). A full sync is simply not usable for this regmap. What does work here: drop the stale cache instead of syncing it, i.e. regcache_drop_region(0, UINT_MAX) before tas_io_init() when the device re-attaches uninitialized, so the following update_bits() calls read real hardware. Side effect: user-set controls fall back to hardware defaults after a resume, which seems the lesser evil versus a silent amp. I will send this as a proper patch. Note for Mark/TI: it will be based on top of 0d6b2d6f93a6 ("ASoC: codecs: tas2783-sdw: Propagate regcache_sync() errors") currently in for-next, which touches the same two call sites. Root cause #2: ACP SoundWire DMA config not reprogrammed on recovery -------------------------------------------------------------------- Even with the cache fixed, sound only returns after the PCM is fully recreated (pactl profile off/on), not after a plain userspace resume. sound/soc/amd/ps/ps-sdw-dma.c advertises SNDRV_PCM_INFO_RESUME, so userspace issues TRIGGER_RESUME (or prepare without hw_params), while the ring-buffer registers (RINGBUFADDR/RINGBUFSIZE, watermark, IRQ masks) are only programmed in hw_params. The DMA is then started with unprogrammed registers: silence, followed by an XRUN. Intel does not set INFO_RESUME on SoundWire for exactly this reason. Dropping INFO_RESUME plus reprogramming the DMA config from .prepare still does not fully restore audio here, so something else is lost across the power gate on the ACP/manager side. I will post that part separately, with traces, addressed to the AMD folks - it does not belong in this codec thread. Happy to test patches on this hardware. [1] https://lore.kernel.org/all/466a905d-8203-46d2-bfe4-a3b3f9b5d68b@montane.tech/ Thanks, Andrey