Currently, on ASUS projects, the TAS2781 codec attaches the speaker GPIO to the first tasdevice_priv instance using devm. This causes tas2781_read_acpi to fail on subsequent probes since the GPIO is already managed by the first device. This causes a failure on Xbox Ally X, because it has two amplifiers, and prevents us from quirking both the Xbox Ally and Xbox Ally X in the realtek codec driver.
It is unnecessary to attach the GPIO to a device as it is static. Therefore, instead of attaching it and then reading it when loading the firmware, read its value directly in tas2781_read_acpi and store it in the private data structure. Then, make reading the value non-fatal so that ASUS projects that miss a speaker pin can still work, perhaps using fallback firmware.
Fixes: 4e7035a75da9 ("ALSA: hda/tas2781: Add speaker id check for ASUS projects") Cc: stable@vger.kernel.org # 6.17 Signed-off-by: Antheas Kapenekakis lkml@antheas.dev --- include/sound/tas2781.h | 2 +- .../hda/codecs/side-codecs/tas2781_hda_i2c.c | 44 +++++++++++-------- 2 files changed, 26 insertions(+), 20 deletions(-)
diff --git a/include/sound/tas2781.h b/include/sound/tas2781.h index 0fbcdb15c74b..29d15ba65f04 100644 --- a/include/sound/tas2781.h +++ b/include/sound/tas2781.h @@ -197,7 +197,6 @@ struct tasdevice_priv { struct acoustic_data acou_data; #endif struct tasdevice_fw *fmw; - struct gpio_desc *speaker_id; struct gpio_desc *reset; struct mutex codec_lock; struct regmap *regmap; @@ -215,6 +214,7 @@ struct tasdevice_priv { unsigned int magic_num; unsigned int chip_id; unsigned int sysclk; + int speaker_id;
int irq; int cur_prog; diff --git a/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c b/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c index 0357401a6023..c8619995b1d7 100644 --- a/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c +++ b/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c @@ -87,6 +87,7 @@ static const struct acpi_gpio_mapping tas2781_speaker_id_gpios[] = {
static int tas2781_read_acpi(struct tasdevice_priv *p, const char *hid) { + struct gpio_desc *speaker_id; struct acpi_device *adev; struct device *physdev; LIST_HEAD(resources); @@ -119,19 +120,31 @@ static int tas2781_read_acpi(struct tasdevice_priv *p, const char *hid) /* Speaker id was needed for ASUS projects. */ ret = kstrtou32(sub, 16, &subid); if (!ret && upper_16_bits(subid) == PCI_VENDOR_ID_ASUSTEK) { - ret = devm_acpi_dev_add_driver_gpios(p->dev, - tas2781_speaker_id_gpios); - if (ret < 0) + ret = acpi_dev_add_driver_gpios(adev, tas2781_speaker_id_gpios); + if (ret < 0) { dev_err(p->dev, "Failed to add driver gpio %d.\n", ret); - p->speaker_id = devm_gpiod_get(p->dev, "speakerid", GPIOD_IN); - if (IS_ERR(p->speaker_id)) { - dev_err(p->dev, "Failed to get Speaker id.\n"); - ret = PTR_ERR(p->speaker_id); - goto err; + p->speaker_id = -1; + goto end_2563; + } + + speaker_id = fwnode_gpiod_get_index(acpi_fwnode_handle(adev), + "speakerid", 0, GPIOD_IN, NULL); + if (!IS_ERR(speaker_id)) { + p->speaker_id = gpiod_get_value_cansleep(speaker_id); + dev_dbg(p->dev, "Got speaker id gpio from ACPI: %d.\n", + p->speaker_id); + gpiod_put(speaker_id); + } else { + p->speaker_id = -1; + ret = PTR_ERR(speaker_id); + dev_err(p->dev, "Get speaker id gpio failed %d.\n", + ret); } + + acpi_dev_remove_driver_gpios(adev); } else { - p->speaker_id = NULL; + p->speaker_id = -1; }
end_2563: @@ -432,23 +445,16 @@ static void tasdevice_dspfw_init(void *context) struct tas2781_hda *tas_hda = dev_get_drvdata(tas_priv->dev); struct tas2781_hda_i2c_priv *hda_priv = tas_hda->hda_priv; struct hda_codec *codec = tas_priv->codec; - int ret, spk_id; + int ret;
tasdevice_dsp_remove(tas_priv); tas_priv->fw_state = TASDEVICE_DSP_FW_PENDING; - if (tas_priv->speaker_id != NULL) { - // Speaker id need to be checked for ASUS only. - spk_id = gpiod_get_value(tas_priv->speaker_id); - if (spk_id < 0) { - // Speaker id is not valid, use default. - dev_dbg(tas_priv->dev, "Wrong spk_id = %d\n", spk_id); - spk_id = 0; - } + if (tas_priv->speaker_id >= 0) { snprintf(tas_priv->coef_binaryname, sizeof(tas_priv->coef_binaryname), "TAS2XXX%04X%d.bin", lower_16_bits(codec->core.subsystem_id), - spk_id); + tas_priv->speaker_id); } else { snprintf(tas_priv->coef_binaryname, sizeof(tas_priv->coef_binaryname),
base-commit: 211ddde0823f1442e4ad052a2f30f050145ccada
Bind the realtek codec to TAS2781 I2C audio amps on ASUS Xbox Ally projects. While these projects work without a quirk, adding it increases the output volume significantly.
Cc: stable@vger.kernel.org # 6.17 Signed-off-by: Antheas Kapenekakis lkml@antheas.dev --- sound/hda/codecs/realtek/alc269.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c index 8ad5febd822a..d1ad84eee6d1 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -6713,6 +6713,8 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1043, 0x12f0, "ASUS X541UV", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1313, "Asus K42JZ", ALC269VB_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1314, "ASUS GA605K", ALC285_FIXUP_ASUS_GA605K_HEADSET_MIC), + SND_PCI_QUIRK(0x1043, 0x1384, "ASUS RC73XA", ALC287_FIXUP_TXNW2781_I2C), + SND_PCI_QUIRK(0x1043, 0x1394, "ASUS RC73YA", ALC287_FIXUP_TXNW2781_I2C), SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", ALC269VB_FIXUP_ASUS_ZENBOOK), SND_PCI_QUIRK(0x1043, 0x1433, "ASUS GX650PY/PZ/PV/PU/PYV/PZV/PIV/PVV", ALC285_FIXUP_ASUS_I2C_HEADSET_MIC),
On Sun, 26 Oct 2025 at 20:16, Antheas Kapenekakis lkml@antheas.dev wrote:
Bind the realtek codec to TAS2781 I2C audio amps on ASUS Xbox Ally projects. While these projects work without a quirk, adding it increases the output volume significantly.
Also, if you can upstream the firmware files: TAS2XXX13840.bin TAS2XXX13841.bin TAS2XXX13940.bin TAS2XXX13941.bin
That would be great :)
Antheas
Cc: stable@vger.kernel.org # 6.17 Signed-off-by: Antheas Kapenekakis lkml@antheas.dev
sound/hda/codecs/realtek/alc269.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c index 8ad5febd822a..d1ad84eee6d1 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -6713,6 +6713,8 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1043, 0x12f0, "ASUS X541UV", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1313, "Asus K42JZ", ALC269VB_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1314, "ASUS GA605K", ALC285_FIXUP_ASUS_GA605K_HEADSET_MIC),
SND_PCI_QUIRK(0x1043, 0x1384, "ASUS RC73XA", ALC287_FIXUP_TXNW2781_I2C),SND_PCI_QUIRK(0x1043, 0x1394, "ASUS RC73YA", ALC287_FIXUP_TXNW2781_I2C), SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", ALC269VB_FIXUP_ASUS_ZENBOOK), SND_PCI_QUIRK(0x1043, 0x1433, "ASUS GX650PY/PZ/PV/PU/PYV/PZV/PIV/PVV", ALC285_FIXUP_ASUS_I2C_HEADSET_MIC),-- 2.51.1
On Oct 26, 2025, at 12:19 PM, Antheas Kapenekakis lkml@antheas.dev wrote:
On Sun, 26 Oct 2025 at 20:16, Antheas Kapenekakis lkml@antheas.dev wrote:
Bind the realtek codec to TAS2781 I2C audio amps on ASUS Xbox Ally projects. While these projects work without a quirk, adding it increases the output volume significantly.
Also, if you can upstream the firmware files: TAS2XXX13840.bin TAS2XXX13841.bin TAS2XXX13940.bin TAS2XXX13941.bin
This is the firmware at [1], correct? I’m testing the series with that firmware on my ROG Xbox Ally X, and I found something interesting.
By default, with just your kernel patches and the firmware files hosted at [1], my unit is loading:
tas2781-hda i2c-TXNW2781:00-tas2781-hda.0: Loaded FW: TAS2XXX13840.bin, sha256: 58cffa36ae23a2d9b2349ecb6c1d4e89627934cd79218f6ada06eaffe6688246
However, with this firmware file, TAS2XXX13840.bin, there is significant audio clipping above 75% speaker level on my individual unit.
Then, I tried renaming the other firmware file, TAS2XXX13841.bin, into TAS2XXX13840.bin. Now my unit is loading:
tas2781-hda i2c-TXNW2781:00-tas2781-hda.0: Loaded FW: TAS2XXX13840.bin, sha256: 0fda76e7142cb455df1860cfdb19bb3cb6871128b385595fe06b296a070f4b8c
With this firmware file, audio is perfect all the way to 100% speaker level.
If I recall, there have been other ASUS products that required matching amplifier hardware with firmware correctly, right? It looks like this might be another case of since it seems my unit is loading the wrong firmware for its amplifiers.
Matt
[1]: https://github.com/hhd-dev/hwfirm
That would be great :)
Antheas
Cc: stable@vger.kernel.org # 6.17 Signed-off-by: Antheas Kapenekakis lkml@antheas.dev
sound/hda/codecs/realtek/alc269.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c index 8ad5febd822a..d1ad84eee6d1 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -6713,6 +6713,8 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1043, 0x12f0, "ASUS X541UV", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1313, "Asus K42JZ", ALC269VB_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1314, "ASUS GA605K", ALC285_FIXUP_ASUS_GA605K_HEADSET_MIC),
SND_PCI_QUIRK(0x1043, 0x1384, "ASUS RC73XA", ALC287_FIXUP_TXNW2781_I2C),SND_PCI_QUIRK(0x1043, 0x1394, "ASUS RC73YA", ALC287_FIXUP_TXNW2781_I2C), SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", ALC269VB_FIXUP_ASUS_ZENBOOK), SND_PCI_QUIRK(0x1043, 0x1433, "ASUS GX650PY/PZ/PV/PU/PYV/PZV/PIV/PVV", ALC285_FIXUP_ASUS_I2C_HEADSET_MIC),-- 2.51.1
On Mon, 27 Oct 2025 at 07:02, Matthew Schwartz matthew.schwartz@linux.dev wrote:
On Oct 26, 2025, at 12:19 PM, Antheas Kapenekakis lkml@antheas.dev wrote:
On Sun, 26 Oct 2025 at 20:16, Antheas Kapenekakis lkml@antheas.dev wrote:
Bind the realtek codec to TAS2781 I2C audio amps on ASUS Xbox Ally projects. While these projects work without a quirk, adding it increases the output volume significantly.
Also, if you can upstream the firmware files: TAS2XXX13840.bin TAS2XXX13841.bin TAS2XXX13940.bin TAS2XXX13941.bin
This is the firmware at [1], correct? I’m testing the series with that firmware on my ROG Xbox Ally X, and I found something interesting.
By default, with just your kernel patches and the firmware files hosted at [1], my unit is loading:
tas2781-hda i2c-TXNW2781:00-tas2781-hda.0: Loaded FW: TAS2XXX13840.bin, sha256: 58cffa36ae23a2d9b2349ecb6c1d4e89627934cd79218f6ada06eaffe6688246
However, with this firmware file, TAS2XXX13840.bin, there is significant audio clipping above 75% speaker level on my individual unit.
Then, I tried renaming the other firmware file, TAS2XXX13841.bin, into TAS2XXX13840.bin. Now my unit is loading:
tas2781-hda i2c-TXNW2781:00-tas2781-hda.0: Loaded FW: TAS2XXX13840.bin, sha256: 0fda76e7142cb455df1860cfdb19bb3cb6871128b385595fe06b296a070f4b8c
With this firmware file, audio is perfect all the way to 100% speaker level.
If I recall, there have been other ASUS products that required matching amplifier hardware with firmware correctly, right? It looks like this might be another case of since it seems my unit is loading the wrong firmware for its amplifiers.
The original Ally X had a similar setup, yes.
First patch might not be perfect and your speaker pin might be 1. My Xbox Ally's pin is 1. It loads: Loaded FW: TAS2XXX13941.bin, sha256: 0fda76e7142cb455df1860cfdb19bb3cb6871128b385595fe06b296a070f4b8c
And it sounds loud and crisp. So the pin is read.
I had multiple users verify the X works, but perhaps it is not perfect yet. Make sure you are not using a dsp that might be interfering
Antheas
Matt
That would be great :)
Antheas
Cc: stable@vger.kernel.org # 6.17 Signed-off-by: Antheas Kapenekakis lkml@antheas.dev
sound/hda/codecs/realtek/alc269.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c index 8ad5febd822a..d1ad84eee6d1 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -6713,6 +6713,8 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1043, 0x12f0, "ASUS X541UV", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1313, "Asus K42JZ", ALC269VB_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1314, "ASUS GA605K", ALC285_FIXUP_ASUS_GA605K_HEADSET_MIC),
SND_PCI_QUIRK(0x1043, 0x1384, "ASUS RC73XA", ALC287_FIXUP_TXNW2781_I2C),SND_PCI_QUIRK(0x1043, 0x1394, "ASUS RC73YA", ALC287_FIXUP_TXNW2781_I2C), SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", ALC269VB_FIXUP_ASUS_ZENBOOK), SND_PCI_QUIRK(0x1043, 0x1433, "ASUS GX650PY/PZ/PV/PU/PYV/PZV/PIV/PVV", ALC285_FIXUP_ASUS_I2C_HEADSET_MIC),-- 2.51.1
On Mon, 27 Oct 2025 at 09:23, Antheas Kapenekakis lkml@antheas.dev wrote:
On Mon, 27 Oct 2025 at 07:02, Matthew Schwartz matthew.schwartz@linux.dev wrote:
On Oct 26, 2025, at 12:19 PM, Antheas Kapenekakis lkml@antheas.dev wrote:
On Sun, 26 Oct 2025 at 20:16, Antheas Kapenekakis lkml@antheas.dev wrote:
Bind the realtek codec to TAS2781 I2C audio amps on ASUS Xbox Ally projects. While these projects work without a quirk, adding it increases the output volume significantly.
Also, if you can upstream the firmware files: TAS2XXX13840.bin TAS2XXX13841.bin TAS2XXX13940.bin TAS2XXX13941.bin
This is the firmware at [1], correct? I’m testing the series with that firmware on my ROG Xbox Ally X, and I found something interesting.
By default, with just your kernel patches and the firmware files hosted at [1], my unit is loading:
tas2781-hda i2c-TXNW2781:00-tas2781-hda.0: Loaded FW: TAS2XXX13840.bin, sha256: 58cffa36ae23a2d9b2349ecb6c1d4e89627934cd79218f6ada06eaffe6688246
However, with this firmware file, TAS2XXX13840.bin, there is significant audio clipping above 75% speaker level on my individual unit.
Then, I tried renaming the other firmware file, TAS2XXX13841.bin, into TAS2XXX13840.bin. Now my unit is loading:
tas2781-hda i2c-TXNW2781:00-tas2781-hda.0: Loaded FW: TAS2XXX13840.bin, sha256: 0fda76e7142cb455df1860cfdb19bb3cb6871128b385595fe06b296a070f4b8c
With this firmware file, audio is perfect all the way to 100% speaker level.
If I recall, there have been other ASUS products that required matching amplifier hardware with firmware correctly, right? It looks like this might be another case of since it seems my unit is loading the wrong firmware for its amplifiers.
The original Ally X had a similar setup, yes.
First patch might not be perfect and your speaker pin might be 1. My Xbox Ally's pin is 1. It loads: Loaded FW: TAS2XXX13941.bin, sha256: 0fda76e7142cb455df1860cfdb19bb3cb6871128b385595fe06b296a070f4b8c
And it sounds loud and crisp. So the pin is read.
I had multiple users verify the X works, but perhaps it is not perfect yet. Make sure you are not using a dsp that might be interfering
Antheas
Matt
[1] is straight from the windows driver with no renaming
That would be great :)
Antheas
Cc: stable@vger.kernel.org # 6.17 Signed-off-by: Antheas Kapenekakis lkml@antheas.dev
sound/hda/codecs/realtek/alc269.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c index 8ad5febd822a..d1ad84eee6d1 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -6713,6 +6713,8 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1043, 0x12f0, "ASUS X541UV", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1313, "Asus K42JZ", ALC269VB_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1314, "ASUS GA605K", ALC285_FIXUP_ASUS_GA605K_HEADSET_MIC),
SND_PCI_QUIRK(0x1043, 0x1384, "ASUS RC73XA", ALC287_FIXUP_TXNW2781_I2C),SND_PCI_QUIRK(0x1043, 0x1394, "ASUS RC73YA", ALC287_FIXUP_TXNW2781_I2C), SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", ALC269VB_FIXUP_ASUS_ZENBOOK), SND_PCI_QUIRK(0x1043, 0x1433, "ASUS GX650PY/PZ/PV/PU/PYV/PZV/PIV/PVV", ALC285_FIXUP_ASUS_I2C_HEADSET_MIC),-- 2.51.1
On 10/27/25 1:23 AM, Antheas Kapenekakis wrote:
On Mon, 27 Oct 2025 at 07:02, Matthew Schwartz matthew.schwartz@linux.dev wrote:
On Oct 26, 2025, at 12:19 PM, Antheas Kapenekakis lkml@antheas.dev wrote:
On Sun, 26 Oct 2025 at 20:16, Antheas Kapenekakis lkml@antheas.dev wrote:
Bind the realtek codec to TAS2781 I2C audio amps on ASUS Xbox Ally projects. While these projects work without a quirk, adding it increases the output volume significantly.
Also, if you can upstream the firmware files: TAS2XXX13840.bin TAS2XXX13841.bin TAS2XXX13940.bin TAS2XXX13941.bin
This is the firmware at [1], correct? I’m testing the series with that firmware on my ROG Xbox Ally X, and I found something interesting.
By default, with just your kernel patches and the firmware files hosted at [1], my unit is loading:
tas2781-hda i2c-TXNW2781:00-tas2781-hda.0: Loaded FW: TAS2XXX13840.bin, sha256: 58cffa36ae23a2d9b2349ecb6c1d4e89627934cd79218f6ada06eaffe6688246
However, with this firmware file, TAS2XXX13840.bin, there is significant audio clipping above 75% speaker level on my individual unit.
Then, I tried renaming the other firmware file, TAS2XXX13841.bin, into TAS2XXX13840.bin. Now my unit is loading:
tas2781-hda i2c-TXNW2781:00-tas2781-hda.0: Loaded FW: TAS2XXX13840.bin, sha256: 0fda76e7142cb455df1860cfdb19bb3cb6871128b385595fe06b296a070f4b8c
With this firmware file, audio is perfect all the way to 100% speaker level.
If I recall, there have been other ASUS products that required matching amplifier hardware with firmware correctly, right? It looks like this might be another case of since it seems my unit is loading the wrong firmware for its amplifiers.
The original Ally X had a similar setup, yes.
First patch might not be perfect and your speaker pin might be 1. My Xbox Ally's pin is 1. It loads: Loaded FW: TAS2XXX13941.bin, sha256: 0fda76e7142cb455df1860cfdb19bb3cb6871128b385595fe06b296a070f4b8c
And it sounds loud and crisp. So the pin is read.
I had multiple users verify the X works, but perhaps it is not perfect yet. Make sure you are not using a dsp that might be interfering
Seems like there have been other reports similar to mine on Xbox Ally X, where flipping the firmware files by renaming them fixes sound issues for them.
@TI, Maybe something is different with the conditional logic for the ROG Xbox Ally X? The current GPIO-detected speaker_id doesn't always correspond to the correct firmware choice on this model it seems.
Antheas
Matt
That would be great :)
Antheas
Cc: stable@vger.kernel.org # 6.17 Signed-off-by: Antheas Kapenekakis lkml@antheas.dev
sound/hda/codecs/realtek/alc269.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c index 8ad5febd822a..d1ad84eee6d1 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -6713,6 +6713,8 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1043, 0x12f0, "ASUS X541UV", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1313, "Asus K42JZ", ALC269VB_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1314, "ASUS GA605K", ALC285_FIXUP_ASUS_GA605K_HEADSET_MIC),
SND_PCI_QUIRK(0x1043, 0x1384, "ASUS RC73XA", ALC287_FIXUP_TXNW2781_I2C),SND_PCI_QUIRK(0x1043, 0x1394, "ASUS RC73YA", ALC287_FIXUP_TXNW2781_I2C), SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", ALC269VB_FIXUP_ASUS_ZENBOOK), SND_PCI_QUIRK(0x1043, 0x1433, "ASUS GX650PY/PZ/PV/PU/PYV/PZV/PIV/PVV", ALC285_FIXUP_ASUS_I2C_HEADSET_MIC),-- 2.51.1
On Mon, 27 Oct 2025 at 20:58, Matthew Schwartz matthew.schwartz@linux.dev wrote:
On 10/27/25 1:23 AM, Antheas Kapenekakis wrote:
On Mon, 27 Oct 2025 at 07:02, Matthew Schwartz matthew.schwartz@linux.dev wrote:
On Oct 26, 2025, at 12:19 PM, Antheas Kapenekakis lkml@antheas.dev wrote:
On Sun, 26 Oct 2025 at 20:16, Antheas Kapenekakis lkml@antheas.dev wrote:
Bind the realtek codec to TAS2781 I2C audio amps on ASUS Xbox Ally projects. While these projects work without a quirk, adding it increases the output volume significantly.
Also, if you can upstream the firmware files: TAS2XXX13840.bin TAS2XXX13841.bin TAS2XXX13940.bin TAS2XXX13941.bin
This is the firmware at [1], correct? I’m testing the series with that firmware on my ROG Xbox Ally X, and I found something interesting.
By default, with just your kernel patches and the firmware files hosted at [1], my unit is loading:
tas2781-hda i2c-TXNW2781:00-tas2781-hda.0: Loaded FW: TAS2XXX13840.bin, sha256: 58cffa36ae23a2d9b2349ecb6c1d4e89627934cd79218f6ada06eaffe6688246
However, with this firmware file, TAS2XXX13840.bin, there is significant audio clipping above 75% speaker level on my individual unit.
Then, I tried renaming the other firmware file, TAS2XXX13841.bin, into TAS2XXX13840.bin. Now my unit is loading:
tas2781-hda i2c-TXNW2781:00-tas2781-hda.0: Loaded FW: TAS2XXX13840.bin, sha256: 0fda76e7142cb455df1860cfdb19bb3cb6871128b385595fe06b296a070f4b8c
With this firmware file, audio is perfect all the way to 100% speaker level.
If I recall, there have been other ASUS products that required matching amplifier hardware with firmware correctly, right? It looks like this might be another case of since it seems my unit is loading the wrong firmware for its amplifiers.
The original Ally X had a similar setup, yes.
First patch might not be perfect and your speaker pin might be 1. My Xbox Ally's pin is 1. It loads: Loaded FW: TAS2XXX13941.bin, sha256: 0fda76e7142cb455df1860cfdb19bb3cb6871128b385595fe06b296a070f4b8c
And it sounds loud and crisp. So the pin is read.
I had multiple users verify the X works, but perhaps it is not perfect yet. Make sure you are not using a dsp that might be interfering
Seems like there have been other reports similar to mine on Xbox Ally X, where flipping the firmware files by renaming them fixes sound issues for them.
@TI, Maybe something is different with the conditional logic for the ROG Xbox Ally X? The current GPIO-detected speaker_id doesn't always correspond to the correct firmware choice on this model it seems.
Yeah, it seems that specifically on the Xbox Ally X, the firmwares are swapped around? What could be the case for that?
I had three users with popping and dropped audio swap the firmware on their X and they said the other one fixed it. And another two without issues swapping the firmware and saying it does not make a quantifiable change.
Antheas
Antheas
Antheas
Matt
That would be great :)
Antheas
Cc: stable@vger.kernel.org # 6.17 Signed-off-by: Antheas Kapenekakis lkml@antheas.dev
sound/hda/codecs/realtek/alc269.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c index 8ad5febd822a..d1ad84eee6d1 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -6713,6 +6713,8 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1043, 0x12f0, "ASUS X541UV", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1313, "Asus K42JZ", ALC269VB_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1314, "ASUS GA605K", ALC285_FIXUP_ASUS_GA605K_HEADSET_MIC),
SND_PCI_QUIRK(0x1043, 0x1384, "ASUS RC73XA", ALC287_FIXUP_TXNW2781_I2C),SND_PCI_QUIRK(0x1043, 0x1394, "ASUS RC73YA", ALC287_FIXUP_TXNW2781_I2C), SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", ALC269VB_FIXUP_ASUS_ZENBOOK), SND_PCI_QUIRK(0x1043, 0x1433, "ASUS GX650PY/PZ/PV/PU/PYV/PZV/PIV/PVV", ALC285_FIXUP_ASUS_I2C_HEADSET_MIC),-- 2.51.1
On Tue, 28 Oct 2025 at 18:27, Antheas Kapenekakis lkml@antheas.dev wrote:
On Mon, 27 Oct 2025 at 20:58, Matthew Schwartz matthew.schwartz@linux.dev wrote:
On 10/27/25 1:23 AM, Antheas Kapenekakis wrote:
On Mon, 27 Oct 2025 at 07:02, Matthew Schwartz matthew.schwartz@linux.dev wrote:
On Oct 26, 2025, at 12:19 PM, Antheas Kapenekakis lkml@antheas.dev wrote:
On Sun, 26 Oct 2025 at 20:16, Antheas Kapenekakis lkml@antheas.dev wrote:
Bind the realtek codec to TAS2781 I2C audio amps on ASUS Xbox Ally projects. While these projects work without a quirk, adding it increases the output volume significantly.
Also, if you can upstream the firmware files: TAS2XXX13840.bin TAS2XXX13841.bin TAS2XXX13940.bin TAS2XXX13941.bin
This is the firmware at [1], correct? I’m testing the series with that firmware on my ROG Xbox Ally X, and I found something interesting.
By default, with just your kernel patches and the firmware files hosted at [1], my unit is loading:
tas2781-hda i2c-TXNW2781:00-tas2781-hda.0: Loaded FW: TAS2XXX13840.bin, sha256: 58cffa36ae23a2d9b2349ecb6c1d4e89627934cd79218f6ada06eaffe6688246
However, with this firmware file, TAS2XXX13840.bin, there is significant audio clipping above 75% speaker level on my individual unit.
Then, I tried renaming the other firmware file, TAS2XXX13841.bin, into TAS2XXX13840.bin. Now my unit is loading:
tas2781-hda i2c-TXNW2781:00-tas2781-hda.0: Loaded FW: TAS2XXX13840.bin, sha256: 0fda76e7142cb455df1860cfdb19bb3cb6871128b385595fe06b296a070f4b8c
With this firmware file, audio is perfect all the way to 100% speaker level.
If I recall, there have been other ASUS products that required matching amplifier hardware with firmware correctly, right? It looks like this might be another case of since it seems my unit is loading the wrong firmware for its amplifiers.
The original Ally X had a similar setup, yes.
First patch might not be perfect and your speaker pin might be 1. My Xbox Ally's pin is 1. It loads: Loaded FW: TAS2XXX13941.bin, sha256: 0fda76e7142cb455df1860cfdb19bb3cb6871128b385595fe06b296a070f4b8c
And it sounds loud and crisp. So the pin is read.
I had multiple users verify the X works, but perhaps it is not perfect yet. Make sure you are not using a dsp that might be interfering
Seems like there have been other reports similar to mine on Xbox Ally X, where flipping the firmware files by renaming them fixes sound issues for them.
@TI, Maybe something is different with the conditional logic for the ROG Xbox Ally X? The current GPIO-detected speaker_id doesn't always correspond to the correct firmware choice on this model it seems.
Yeah, it seems that specifically on the Xbox Ally X, the firmwares are swapped around? What could be the case for that?
I had three users with popping and dropped audio swap the firmware on their X and they said the other one fixed it. And another two without issues swapping the firmware and saying it does not make a quantifiable change.
Update on this. Users with a pin value of 1 are happy with the 1 firmware. Users with a value of 0 are not happy with TAS2XXX13840 and TAS2XXX13841 works better for them. Moreover, users of the 1 firmware are not happy with the 0 firmware.
This is just on the Ally X, on the normal Ally there are no issues.
So there is an issue with TAS2XXX13840 on the linux side, TAS2XXX13841 is correctly selected.
Antheas
Antheas
Antheas
Antheas
Matt
That would be great :)
Antheas
Cc: stable@vger.kernel.org # 6.17 Signed-off-by: Antheas Kapenekakis lkml@antheas.dev
sound/hda/codecs/realtek/alc269.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c index 8ad5febd822a..d1ad84eee6d1 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -6713,6 +6713,8 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1043, 0x12f0, "ASUS X541UV", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1313, "Asus K42JZ", ALC269VB_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1314, "ASUS GA605K", ALC285_FIXUP_ASUS_GA605K_HEADSET_MIC),
SND_PCI_QUIRK(0x1043, 0x1384, "ASUS RC73XA", ALC287_FIXUP_TXNW2781_I2C),SND_PCI_QUIRK(0x1043, 0x1394, "ASUS RC73YA", ALC287_FIXUP_TXNW2781_I2C), SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", ALC269VB_FIXUP_ASUS_ZENBOOK), SND_PCI_QUIRK(0x1043, 0x1433, "ASUS GX650PY/PZ/PV/PU/PYV/PZV/PIV/PVV", ALC285_FIXUP_ASUS_I2C_HEADSET_MIC),-- 2.51.1
On Sun, 2 Nov 2025 at 18:33, Antheas Kapenekakis lkml@antheas.dev wrote:
On Tue, 28 Oct 2025 at 18:27, Antheas Kapenekakis lkml@antheas.dev wrote:
On Mon, 27 Oct 2025 at 20:58, Matthew Schwartz matthew.schwartz@linux.dev wrote:
On 10/27/25 1:23 AM, Antheas Kapenekakis wrote:
On Mon, 27 Oct 2025 at 07:02, Matthew Schwartz matthew.schwartz@linux.dev wrote:
On Oct 26, 2025, at 12:19 PM, Antheas Kapenekakis lkml@antheas.dev wrote:
On Sun, 26 Oct 2025 at 20:16, Antheas Kapenekakis lkml@antheas.dev wrote: > > Bind the realtek codec to TAS2781 I2C audio amps on ASUS Xbox Ally > projects. While these projects work without a quirk, adding it increases > the output volume significantly.
Also, if you can upstream the firmware files: TAS2XXX13840.bin TAS2XXX13841.bin TAS2XXX13940.bin TAS2XXX13941.bin
This is the firmware at [1], correct? I’m testing the series with that firmware on my ROG Xbox Ally X, and I found something interesting.
By default, with just your kernel patches and the firmware files hosted at [1], my unit is loading:
tas2781-hda i2c-TXNW2781:00-tas2781-hda.0: Loaded FW: TAS2XXX13840.bin, sha256: 58cffa36ae23a2d9b2349ecb6c1d4e89627934cd79218f6ada06eaffe6688246
However, with this firmware file, TAS2XXX13840.bin, there is significant audio clipping above 75% speaker level on my individual unit.
Then, I tried renaming the other firmware file, TAS2XXX13841.bin, into TAS2XXX13840.bin. Now my unit is loading:
tas2781-hda i2c-TXNW2781:00-tas2781-hda.0: Loaded FW: TAS2XXX13840.bin, sha256: 0fda76e7142cb455df1860cfdb19bb3cb6871128b385595fe06b296a070f4b8c
With this firmware file, audio is perfect all the way to 100% speaker level.
If I recall, there have been other ASUS products that required matching amplifier hardware with firmware correctly, right? It looks like this might be another case of since it seems my unit is loading the wrong firmware for its amplifiers.
The original Ally X had a similar setup, yes.
First patch might not be perfect and your speaker pin might be 1. My Xbox Ally's pin is 1. It loads: Loaded FW: TAS2XXX13941.bin, sha256: 0fda76e7142cb455df1860cfdb19bb3cb6871128b385595fe06b296a070f4b8c
And it sounds loud and crisp. So the pin is read.
I had multiple users verify the X works, but perhaps it is not perfect yet. Make sure you are not using a dsp that might be interfering
Seems like there have been other reports similar to mine on Xbox Ally X, where flipping the firmware files by renaming them fixes sound issues for them.
@TI, Maybe something is different with the conditional logic for the ROG Xbox Ally X? The current GPIO-detected speaker_id doesn't always correspond to the correct firmware choice on this model it seems.
Yeah, it seems that specifically on the Xbox Ally X, the firmwares are swapped around? What could be the case for that?
I had three users with popping and dropped audio swap the firmware on their X and they said the other one fixed it. And another two without issues swapping the firmware and saying it does not make a quantifiable change.
Update on this. Users with a pin value of 1 are happy with the 1 firmware. Users with a value of 0 are not happy with TAS2XXX13840 and TAS2XXX13841 works better for them. Moreover, users of the 1 firmware are not happy with the 0 firmware.
This is just on the Ally X, on the normal Ally there are no issues.
So there is an issue with TAS2XXX13840 on the linux side, TAS2XXX13841 is correctly selected.
Hi, can I get a small bump on this?
Baojun can you comment on the first patch? The fix works properly during our testing.
Both patches do.
It seems there is a problem with firmware file TAS2XXX13840 and devices that select it. Those devices work fine with TAS2XXX13841 and we replaced 0 with it for now, all of them do. The problem with it is that the speakers clip on and off above 80% volume when TAS2XXX13840 is loaded.
Unfortunately I do not have an affected X unit, only a non-X one that works fine with the 13941 project. Mat does and he could do some testing.
Antheas
Antheas
Antheas
Antheas
Matt
That would be great :)
Antheas
> Cc: stable@vger.kernel.org # 6.17 > Signed-off-by: Antheas Kapenekakis lkml@antheas.dev > --- > sound/hda/codecs/realtek/alc269.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c > index 8ad5febd822a..d1ad84eee6d1 100644 > --- a/sound/hda/codecs/realtek/alc269.c > +++ b/sound/hda/codecs/realtek/alc269.c > @@ -6713,6 +6713,8 @@ static const struct hda_quirk alc269_fixup_tbl[] = { > SND_PCI_QUIRK(0x1043, 0x12f0, "ASUS X541UV", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), > SND_PCI_QUIRK(0x1043, 0x1313, "Asus K42JZ", ALC269VB_FIXUP_ASUS_MIC_NO_PRESENCE), > SND_PCI_QUIRK(0x1043, 0x1314, "ASUS GA605K", ALC285_FIXUP_ASUS_GA605K_HEADSET_MIC), > + SND_PCI_QUIRK(0x1043, 0x1384, "ASUS RC73XA", ALC287_FIXUP_TXNW2781_I2C), > + SND_PCI_QUIRK(0x1043, 0x1394, "ASUS RC73YA", ALC287_FIXUP_TXNW2781_I2C), > SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE), > SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", ALC269VB_FIXUP_ASUS_ZENBOOK), > SND_PCI_QUIRK(0x1043, 0x1433, "ASUS GX650PY/PZ/PV/PU/PYV/PZV/PIV/PVV", ALC285_FIXUP_ASUS_I2C_HEADSET_MIC), > -- > 2.51.1 > >
From: Antheas Kapenekakis lkml@antheas.dev Sent: 27 October 2025 03:16 To: Ding, Shenghao; Xu, Baojun Cc: Takashi Iwai; linux-sound@vger.kernel.org; linux-kernel@vger.kernel.org; Antheas Kapenekakis; stable@vger.kernel.org Subject: [EXTERNAL] [PATCH v1 1/2] ALSA: hda/tas2781: fix speaker id retrieval for multiple probes
Currently, on ASUS projects, the TAS2781 codec attaches the speaker GPIO to the first tasdevice_priv instance using devm. This causes tas2781_read_acpi to fail on subsequent probes since the GPIO is already managed by the first device. This causes a failure on Xbox Ally X, because it has two amplifiers, and prevents us from quirking both the Xbox Ally and Xbox Ally X in the realtek codec driver.
It is unnecessary to attach the GPIO to a device as it is static. Therefore, instead of attaching it and then reading it when loading the firmware, read its value directly in tas2781_read_acpi and store it in the private data structure. Then, make reading the value non-fatal so that ASUS projects that miss a speaker pin can still work, perhaps using fallback firmware.
Fixes: 4e7035a75da9 ("ALSA: hda/tas2781: Add speaker id check for ASUS projects") Cc: stable@vger.kernel.org # 6.17 Signed-off-by: Antheas Kapenekakis lkml@antheas.dev
include/sound/tas2781.h | 2 +- .../hda/codecs/side-codecs/tas2781_hda_i2c.c | 44 +++++++++++-------- 2 files changed, 26 insertions(+), 20 deletions(-)
Reviewed-by: Baojun Xu baojun.xu@ti.com
Best Regards Jim
On Tue, 18 Nov 2025 03:31:32 +0100, Xu, Baojun wrote:
From: Antheas Kapenekakis lkml@antheas.dev Sent: 27 October 2025 03:16 To: Ding, Shenghao; Xu, Baojun Cc: Takashi Iwai; linux-sound@vger.kernel.org; linux-kernel@vger.kernel.org; Antheas Kapenekakis; stable@vger.kernel.org Subject: [EXTERNAL] [PATCH v1 1/2] ALSA: hda/tas2781: fix speaker id retrieval for multiple probes
Currently, on ASUS projects, the TAS2781 codec attaches the speaker GPIO to the first tasdevice_priv instance using devm. This causes tas2781_read_acpi to fail on subsequent probes since the GPIO is already managed by the first device. This causes a failure on Xbox Ally X, because it has two amplifiers, and prevents us from quirking both the Xbox Ally and Xbox Ally X in the realtek codec driver.
It is unnecessary to attach the GPIO to a device as it is static. Therefore, instead of attaching it and then reading it when loading the firmware, read its value directly in tas2781_read_acpi and store it in the private data structure. Then, make reading the value non-fatal so that ASUS projects that miss a speaker pin can still work, perhaps using fallback firmware.
Fixes: 4e7035a75da9 ("ALSA: hda/tas2781: Add speaker id check for ASUS projects") Cc: stable@vger.kernel.org # 6.17 Signed-off-by: Antheas Kapenekakis lkml@antheas.dev
include/sound/tas2781.h | 2 +- .../hda/codecs/side-codecs/tas2781_hda_i2c.c | 44 +++++++++++-------- 2 files changed, 26 insertions(+), 20 deletions(-)
Reviewed-by: Baojun Xu baojun.xu@ti.com
OK, I applied both patches to for-next branch now.
For the remaining issues, let's fix on the top.
thanks,
Takashi
linux-stable-mirror@lists.linaro.org