From: Matthew Schwartz <matthew.schwartz@linux.dev>
To: Antheas Kapenekakis <lkml@antheas.dev>
Cc: Shenghao Ding <shenghao-ding@ti.com>,
Baojun Xu <baojun.xu@ti.com>,
tiwai@suse.de, linux-kernel@vger.kernel.org,
linux-sound@vger.kernel.org,
Antheas Kapenekakis <lkml@antheas.dev>
Subject: Re: [PATCH v1] ALSA: hda/tas2781: Prevent throwing away custom calibration addresses
Date: Wed, 7 Jan 2026 02:17:35 -0800 [thread overview]
Message-ID: <862C1A43-9C43-404F-A940-920FCD7D1919@linux.dev> (raw)
> On Jan 7, 2026, at 1:32 AM, Antheas Kapenekakis <lkml@antheas.dev> wrote:
>
> The V2 UEFI spec for per-device calibration data in TAS allows for
> manufacturers to specify up to five custom calibration register
> addresses and values to optimize per-device in factory.
>
> A basic description of the spec is found in a comment in function
> tas2781_apply_calib(). However, currently, for the condition of
> p->dspbin_typ != TASDEV_BASIC, if custom calibration addresses have been
> provided by the manufacturer, they are ignored and the ones listed in
> firmware are used.
>
> In case the manufacturer chose to change different registers other than
> the default ones (r0, invr0, r0_low, pow, tlimit), this causes the
> UEFI calibration data to scratch different registers and cause the
> firmware to misbehave. This is true in the Xbox ROG Ally X, for one of
> the firmwares, where it pops and has audio dropouts after the
> calibration data is applied.
>
> Therefore, add a new bool to indicate that UEFI supplied custom
> calibration addresses, and if so, use them regardless of dspbin_typ.
>
> Link: https://lore.kernel.org/all/CAGwozwFQKoQgo_Q=qdr-FTD+uoVWA8AtHyDmKwTOV4ZU6+F3SQ@mail.gmail.com/
> Reported-by: Matthew Schwartz <matthew.schwartz@linux.dev>
> Closes: https://lore.kernel.org/all/0ba100d0-9b6f-4a3b-bffa-61abe1b46cd5@linux.dev/
> Co-developed-by: Matthew Schwartz <matthew.schwartz@linux.dev>
> Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev>
> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
>
> ---
> @Matt: can you kindly verify this patch works for you?
I’ll have time to debug it more in the morning but the patch does not work, it’s still using the same calibrated data as before with dropouts.
>
> Then verify your sign-off for the coby tag. If you would rather a
> different acknowledgment tag (e.g., tested-by or suggested-by), lmk
>
> Thanks.
> Antheas
> ---
> sound/hda/codecs/side-codecs/tas2781_hda.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/sound/hda/codecs/side-codecs/tas2781_hda.c b/sound/hda/codecs/side-codecs/tas2781_hda.c
> index 96e6d82dc69e..6efdf0a3442b 100644
> --- a/sound/hda/codecs/side-codecs/tas2781_hda.c
> +++ b/sound/hda/codecs/side-codecs/tas2781_hda.c
> @@ -64,6 +64,7 @@ static void tas2781_apply_calib(struct tasdevice_priv *p)
> TASDEVICE_REG(0, 0x18, 0x7c),
> };
> unsigned int crc, oft, node_num;
> + bool custom_addr = false;
> unsigned char *buf;
> int i, j, k, l;
>
> @@ -104,6 +105,7 @@ static void tas2781_apply_calib(struct tasdevice_priv *p)
> for (j = 0, k = 0; j < node_num; j++) {
> oft = j * 6 + 3;
> if (tmp_val[oft] == TASDEV_UEFI_CALI_REG_ADDR_FLG) {
> + custom_addr = true;
> for (i = 0; i < TASDEV_CALIB_N; i++) {
> buf = &data[(oft + i + 1) * 4];
> cali_reg[i] = TASDEVICE_REG(buf[1],
> @@ -151,7 +153,7 @@ static void tas2781_apply_calib(struct tasdevice_priv *p)
> }
> }
>
> - if (p->dspbin_typ == TASDEV_BASIC) {
> + if (custom_addr || p->dspbin_typ == TASDEV_BASIC) {
> r->r0_reg = cali_reg[0];
> r->invr0_reg = cali_reg[1];
> r->r0_low_reg = cali_reg[2];
>
> base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb
> --
> 2.52.0
next reply other threads:[~2026-01-07 10:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-07 10:17 Matthew Schwartz [this message]
2026-01-07 10:21 ` [PATCH v1] ALSA: hda/tas2781: Prevent throwing away custom calibration addresses Antheas Kapenekakis
2026-01-08 3:29 ` Matthew Schwartz
2026-01-08 8:22 ` Antheas Kapenekakis
-- strict thread matches above, loose matches on Subject: below --
2026-01-07 9:31 Antheas Kapenekakis
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=862C1A43-9C43-404F-A940-920FCD7D1919@linux.dev \
--to=matthew.schwartz@linux.dev \
--cc=baojun.xu@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=lkml@antheas.dev \
--cc=shenghao-ding@ti.com \
--cc=tiwai@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox