From: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
To: Matthew Schwartz <matthew.schwartz@linux.dev>, broonie@kernel.org
Cc: Lee Mann <leepaulmann@gmail.com>,
Shenghao Ding <shenghao-ding@ti.com>, Kevin Lu <kevin-lu@ti.com>,
Baojun Xu <baojun.xu@ti.com>, Sen Wang <sen@ti.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
Andrey Golovko <andrey.golovko@gmail.com>,
linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] ASoC: tas2783-sdw: keep the volume settings across resets
Date: Tue, 20 Oct 2026 22:41:43 +0200 [thread overview]
Message-ID: <caf02dc9-cd1a-4acb-b7eb-b65d46b89f9d@linux.dev> (raw)
In-Reply-To: <4c1a8b04-d873-4395-badb-2762e6c40f59@linux.dev>
On 10/19/26 19:53, Matthew Schwartz wrote:
> On 10/19/26 8:56 AM, Pierre-Louis Bossart wrote:
>> On 10/18/26 22:00, Matthew Schwartz wrote:
>>> The register cache is dropped when the amp attaches uninitialized and
>>> again after the firmware download, so the Amp Volume and Speaker Volume
>>> registers are not cached while the amp is runtime suspended, and every
>>> read or write of those controls fails with -EBUSY. On a platform that
>>> powers the SoundWire link off when idle, such as the ASUS ROG Xbox Ally
>>> X20, the amp is also reset and initialized again on every wake, so a
>>> volume set while it was awake is lost the next time the link idles.
>>>
>>> Keep both settings in the driver, as the cache has to be dropped
>>> whenever the reset and the firmware download change registers behind
>>> it. Reads return the kept value, a write reaches the device only while
>>> it is runtime active and initialized, and the settings are programmed
>>> again after every init and resume. Until userspace sets a control, the
>>> value the firmware leaves after each init is adopted instead, so its
>>> tuning stays in effect. Waking the amp for a control access would
>>> instead cost a full init of both X20 amps, about 0.2 s each.
>>>
>>> Fixes: b627da430357 ("ASoC: tas2783-sdw: drop stale regcache on uninitialized re-attach")
>>
>> Erm, not sure what to think about this fix of a fix.
>>
>> This commit b627da430357 introduced the regcache_drop_region() for all
>> kinds of reasons, and now this new patch introduces a manual management
>> of the volume registers - but why limit this management to volume
>> settings only? Shouldn't other features such as e.g. bass boost or EQ
>> also be restored?
>>
>> It really feels like the problem is that the regmap is not properly
>> restored...at the end of the day, this driver is missing a
>> regcache_sync(), no?
>
> The driver only has the two volume controls, there's no bass boost or
> EQ control. The rest of the tuning comes from the firmware, which
> tas_io_init() writes again on every init, apart from a retained PRAM.
>
> A regcache_sync() can't restore these two because the firmware
> download writes registers with sdw_nwrite_no_pm(), behind the cache,
> and that includes AMP_LEVEL. Of the 72 TAS2783 files in linux-firmware,
> 44 set it to something other than the 0x28 in tas2783_reg_default[],
> mostly levels 9 to 16, and two set DVC to 0x04 instead of 0x00.
> Syncing the default values would replace that per-platform tuning with
> full gain. So the driver has to know whether userspace set a value,
> which needs restoring, or left it alone, in which case the firmware's
> value should stay, and regmap doesn't track that per register.
>
> The volume was also lost before b627da430357, since the sync ran
> before the reset wiped it. The Fixes tag is for the -EBUSY that commit
> added when reading an uncached volume register while the amp is
> runtime suspended.
>
> Certainly open to suggestions for improvement here if there's a simpler
> way to fix this.
I am afraid I don't fully grasp the intended design, with a regmap
default, a firmware download that modifies volume settings but doesn't
update the regmap value, and last a userspace-defined volume that can
override a platform-specific tuned value. It's a recipe for inconsistent
register settings...
next prev parent reply other threads:[~2026-10-20 20:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-18 20:00 [PATCH 0/3] ASoC: tas2783-sdw: volume and firmware load fixes Matthew Schwartz
2026-10-18 20:00 ` [PATCH 1/3] ASoC: tas2783-sdw: keep the volume settings across resets Matthew Schwartz
2026-10-19 15:56 ` Pierre-Louis Bossart
2026-10-19 17:53 ` Matthew Schwartz
2026-10-20 20:41 ` Pierre-Louis Bossart [this message]
2026-10-21 0:04 ` Matthew Schwartz
2026-10-18 20:00 ` [PATCH 2/3] ASoC: tas2783-sdw: load the firmware synchronously Matthew Schwartz
2026-10-19 16:04 ` Pierre-Louis Bossart
2026-10-19 17:58 ` Matthew Schwartz
2026-10-18 20:00 ` [PATCH 3/3] ASoC: tas2783-sdw: refuse playback when the init writes failed Matthew Schwartz
2026-10-19 16:10 ` Pierre-Louis Bossart
2026-10-19 18:01 ` Matthew Schwartz
2026-10-18 23:03 ` [PATCH 0/3] ASoC: tas2783-sdw: volume and firmware load fixes Lee Mann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=caf02dc9-cd1a-4acb-b7eb-b65d46b89f9d@linux.dev \
--to=pierre-louis.bossart@linux.dev \
--cc=andrey.golovko@gmail.com \
--cc=baojun.xu@ti.com \
--cc=broonie@kernel.org \
--cc=kevin-lu@ti.com \
--cc=leepaulmann@gmail.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=matthew.schwartz@linux.dev \
--cc=perex@perex.cz \
--cc=sen@ti.com \
--cc=shenghao-ding@ti.com \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.