sound/soc/codecs/rt721-sdca-sdw.c | 7 +++ sound/soc/codecs/rt721-sdca.c | 97 +++++++++++++++++++++++++++++++ sound/soc/codecs/rt721-sdca.h | 10 ++++ 3 files changed, 114 insertions(+)
Hi Cristian,
Could you check if the attached patch fix the issue?
Thanks.
Regards,
Jack
> -----Original Message-----
> From: Cristian Timohi <cristiantimohi@gmail.com>
> Sent: Tuesday, September 15, 2026 2:52 AM
> To: Mark Brown <broonie@kernel.org>
> Cc: Shengyu Qu <wiagn233@outlook.com>; Jack Yu <jack.yu@realtek.com>;
> Syed Saba Kareem <syed.sabakareem@amd.com>; Mukunda,Vijendar
> <vijendar.mukunda@amd.com>; Flove(HsinFu) <flove@realtek.com>;
> venkataprasad.potturu@amd.com; linux-sound@vger.kernel.org; Oder Chiou
> <oder_chiou@realtek.com>; vkoul@kernel.org;
> yung-chuan.liao@linux.intel.com; pierre-louis.bossart@linux.dev;
> lgirdwood@gmail.com; linux-kernel@vger.kernel.org; Dommati, Sunil-kumar
> <Sunil-kumar.Dommati@amd.com>; Fish690103 <fish690103@realtek.com>;
> Mike Lin (林曉能) <mikelin@realtek.com>
> Subject: Re: [BUG] ASoC/AMD ACP70/RT721: ASUS TUF Gaming A14 FA401EA
> speakers silent and headphone jack buzzes on playback
>
>
> External mail : This email originated from outside the organization. Do not
> reply, click links, or open attachments unless you recognize the sender and
> know the content is safe.
>
>
>
> Hi Mark, Jack, Shengyu, all,
>
> I performed the test Jack requested for NID 0x5f / index 0x30 on my affected
> ASUS TUF Gaming A14 FA401EA.
>
> I am including all details below because there were a few important
> observations during the test.
>
> One note before the technical details: I am not a Linux kernel/audio developer,
> and this level of ASoC/SoundWire/RT721 debugging is beyond my normal area
> of expertise. I am working through these tests with ChatGPT helping me
> understand the driver code, build temporary diagnostic modules, and perform
> the tests carefully.
>
> I am trying to keep every experiment minimal, reversible, and verified by
> readback where possible. I hope the results are still useful for debugging the
> actual issue.
>
> ---
>
> ## SYSTEM
>
> Laptop:
> ASUS TUF Gaming A14 FA401EA
>
> CPU/platform:
> Ryzen AI MAX+ 392
> AMD ACP 7.0
>
> Codec:
> Realtek RT721 SDCA
>
> BIOS:
> FA401EA.304
>
> This machine is already running the latest firmware/BIOS currently available
> for the FA401EA. Therefore, at least on this unit, the issue is reproducible with
> the latest available ASUS firmware installed.
>
> Running kernel:
> 7.3.0-rc2-fa401ea-rt721+
>
> Kernel source tree HEAD:
> 1a3fdcb408 ASoC: rt721-sdca: Adjust latency control to fix no-sound issue
>
> This includes the a20afec40ea1 fix.
>
> The following patch was NOT present during this test:
>
> ASoC: rt721-sdca: Update preset for all functions
>
> Audio card:
>
> amd-soundwire
> ASUSTeKCOMPUTERINC.-TUFGamingA14FA401EA-1.0-FA401EA
>
> SmartMic capture PCM:
>
> card: amdsoundwire
> device 4: SDW1-PIN5-CAPTURE-SmartMic
> DAI: rt721-sdca-aif3-4
>
> ---
>
> ## DIAGNOSTIC MODULE
>
> I built a temporary out-of-tree snd-soc-rt721-sdca module matching the
> running kernel.
>
> No DKMS installation was performed and no permanent module replacement
> was made.
>
> The temporary module initially only did the following:
>
> 1. Added MBQ address 0x5f00030 to the readable and volatile register lists.
>
> 2. Added rt_sdca_index_read() calls inside:
>
> rt721_sdca_pde11_event()
>
> to read:
>
> NID: 0x5f
> index: 0x30
>
> at three points:
>
> * before requesting mic-path PS0
> * after requesting mic-path PS0
> * before requesting PS3
>
> The existing PDE2A power-state request itself was left unchanged.
>
> ---
>
> ## BASELINE READ-ONLY TEST
>
> Before capture I enabled:
>
> rt721 FU1E Capture Switch = on,on,on,on
>
> Capture command:
>
> arecord -D hw:amdsoundwire,4
> -f S16_LE
> -r 48000
> -c 2
> -d 3
> /tmp/rt721-mic-test.wav
>
> The register values were:
>
> RT721TEST mic 5f:30 before PS0: 0xffb7
> RT721TEST mic 5f:30 after PS0: 0xffb7
> RT721TEST mic 5f:30 before PS3: 0xffb7
>
> Therefore, on my affected FA401EA:
>
> 0x5f:0x30 = 0xffb7
>
> and requesting PDE2A PS0 does NOT change it.
>
> I then analyzed the raw PCM samples.
>
> Capture:
>
> 144000 frames
> 48000 Hz
> stereo
> S16_LE
> 3 seconds
>
> Channel 0:
>
> min=0
> max=0
> RMS=0.00
> nonzero samples=0/144000
> nonzero percentage=0.00%
> distinct sample values=1
>
> Channel 1:
>
> min=0
> max=0
> RMS=0.00
> nonzero samples=0/144000
> nonzero percentage=0.00%
> distinct sample values=1
>
> So the SmartMic capture is exact digital zero on both channels.
>
> ---
>
> ## 0xFFB7 VS 0xFFF7
>
> Jack mentioned that the default value according to the RT721 specification for:
>
> NID 0x5f
> index 0x30
>
> is:
>
> 0xfff7
>
> My hardware returns:
>
> 0xffb7
>
> Difference:
>
> 0xfff7
> 0xffb7
> ------
>
> 0x0040
>
> So BIT(6) is the only difference between the value observed on my unit and
> 0xfff7.
>
> ---
>
> ## FIRST ATTEMPT TO FORCE BIT(6)
>
> I then modified the temporary module to set only BIT(6) using:
>
> rt_sdca_index_update_bits(..., BIT(6), BIT(6))
>
> rather than overwriting the entire register.
>
> This should change:
>
> 0xffb7 -> 0xfff7
>
> In the first attempt I performed this before requesting PS0.
>
> That attempt failed safely:
>
> RT721TEST mic 5f:30 before PS0: read failed: -16 RT721TEST force BIT6 failed:
> -16
>
> -16 is EBUSY.
>
> Since rt_sdca_index_update_bits() first reads the register and returns
> immediately if the read fails, no register write occurred during this first
> attempt.
>
> After PS0 the register became readable and still contained:
>
> 0xffb7
>
> There was also a runtime PM issue during this attempt:
>
> runtime PM trying to activate child device sdw:0:1:025d:0721:01 but parent
> (sdw-master-0-1) is not active
>
> followed by:
>
> Failed to resume device: -61
> Slave 1 alert handling failed: -61
>
> Because of this I did not consider the first attempt authoritative.
>
> ---
>
> ## FINAL CONTROLLED TEST
>
> For the second attempt I moved the BIT(6) update until AFTER PDE2A had been
> requested to PS0.
>
> I also explicitly kept the complete relevant path runtime-active during the
> experiment.
>
> ACP PCI device:
>
> /sys/bus/pci/devices/0000:64:00.5
>
> SoundWire manager:
>
> /sys/devices/pci0000:00/0000:00:08.1/0000:64:00.5/amd_sdw_manager.1
>
> RT721 codec:
>
> /sys/bus/soundwire/devices/sdw:0:1:025d:0721:01
>
> For all three:
>
> power/control = on
> runtime_status = active
>
> PipeWire, WirePlumber and alsa-state were stopped during the experiment so
> nothing else held the ALSA devices.
>
> RT721 status before capture:
>
> Attached
>
> The sequence inside rt721_sdca_pde11_event() was:
>
> 1. Read 0x5f:0x30
> 2. Request PDE2A PS0
> 3. Wait 10-20 ms
> 4. Read 0x5f:0x30 again
> 5. Set only BIT(6)
> 6. Read 0x5f:0x30 again to verify the write 7. Perform SmartMic capture 8.
> Read 0x5f:0x30 before PS3 9. Clear BIT(6) again 10. Read back the register to
> verify restoration 11. Request PS3
>
> The resulting kernel log was:
>
> RT721_BIT6_V2_BEGIN
>
> RT721TEST mic 5f:30 before PS0: 0xffb7
> RT721TEST mic 5f:30 after PS0: 0xffb7
> RT721TEST mic 5f:30 after BIT6 set: 0xfff7 RT721TEST mic 5f:30 before PS3:
> 0xfff7 RT721TEST mic 5f:30 after BIT6 restore: 0xffb7
>
> RT721_BIT6_V2_END
>
> So the requested value was successfully written and verified by hardware
> readback.
>
> During the entire three-second capture:
>
> 0x5f:0x30 = 0xfff7
>
> After capture, BIT(6) was cleared again and readback confirmed that the
> original value was restored:
>
> 0x5f:0x30 = 0xffb7
>
> ---
>
> ## CAPTURE RESULT WITH 0x5F:0x30 = 0xFFF7
>
> Capture command:
>
> arecord -D hw:amdsoundwire,4
> -f S16_LE
> -r 48000
> -c 2
> -d 3
> /tmp/rt721-mic-bit6-v2.wav
>
> Capture:
>
> 144000 frames
> 48000 Hz
> stereo
> S16_LE
>
> Channel 0:
>
> min=0
> max=0
> RMS=0.00
> nonzero samples=0/144000
> nonzero percentage=0.00%
> distinct sample values=1
>
> Channel 1:
>
> min=0
> max=0
> RMS=0.00
> nonzero samples=0/144000
> nonzero percentage=0.00%
> distinct sample values=1
>
> Therefore the microphone capture remained exact digital zero on both
> channels even while 0x5f:0x30 was verified to be 0xfff7.
>
> ---
>
> ## SUMMARY
>
> Firmware:
>
> BIOS FA401EA.304
> Latest currently available firmware for FA401EA Issue still reproducible
>
> Baseline:
>
> 0x5f:0x30 = 0xffb7
> DMIC = exact digital zero
>
> Normal PDE2A -> PS0:
>
> 0x5f:0x30 remains 0xffb7
>
> Explicit BIT(6) set:
>
> 0x5f:0x30 becomes 0xfff7
> hardware readback confirms 0xfff7
>
> SmartMic capture while register is 0xfff7:
>
> Channel 0 = exact digital zero
> Channel 1 = exact digital zero
>
> After capture:
>
> BIT(6) cleared
> 0x5f:0x30 returns to 0xffb7
>
> ---
>
> ## CONCLUSION
>
> On my affected FA401EA, explicitly setting NID 0x5f / index 0x30 to the
> specification default value 0xfff7 is NOT sufficient to make the microphones
> work.
>
> The machine is already running BIOS FA401EA.304, which is the latest
> firmware currently available for this model, and the issue is still reproducible.
> Therefore there is no newer ASUS firmware currently available for me to test
> against this behavior.
>
> One interesting difference from the earlier reported register dump is that my
> unit does not currently show 0x01c2 at 0x5f:0x30.
>
> It shows:
>
> 0xffb7
>
> both before and after the normal PDE2A PS0 request.
>
> The only difference from the documented default value 0xfff7 is BIT(6).
>
> However, setting BIT(6), verifying 0xfff7 by hardware readback, and keeping
> that value for the entire capture still leaves both microphone channels
> producing exact digital zeros.
>
> This seems to suggest that some other part of the analog/vendor power
> sequence is still required.
>
> This could also explain why the community workaround which writes several
> RT721 vendor analog power registers succeeds: that workaround modifies
> considerably more than 0x5f:0x30, including codec-wide power state at
> 0x5f:0x00 and other analog power registers.
>
> I intentionally did NOT apply the complete vendor power sequence during this
> test because I wanted to test Jack's 0x5f:0x30 question independently and
> provide a clean result.
>
> For reference, the internal speakers also remain completely silent on this
> machine with a20afec40ea1 alone, as previously reported.
>
> If you would like me to perform another targeted test, please specify the exact
> register/value and at what state it should be read or written, and I will try to
> reproduce it carefully.
>
> Again, I am not experienced with Linux audio driver development and I am
> relying on ChatGPT to help me understand the kernel code and construct these
> diagnostic tests. I wanted to be transparent about that.
>
> Nevertheless, I have tried to keep the experiments minimal and reversible and
> to verify register changes by hardware readback wherever possible.
>
> I hope these results help narrow down the issue.
>
> Thanks,
> Cristian
>
>
> On Mon, Sep 14, 2026 at 9:13 PM Mark Brown <broonie@kernel.org> wrote:
> >
> > On Mon, Sep 14, 2026 at 08:16:22PM +0800, Shengyu Qu wrote:
> >
> > > On my FA401EA this issue doesn't exist so I can't test. Maybe you
> > > can ask at bugzilla so other users with this issue could test?
> >
> > > PS: maybe this is the issue for some old batches of RT721 chip? My
> > > device is very new and this might be why I don't have this issue?
> >
> > Could some firmware update have done something that helps somehow?
From 2575202d5e76e5b248f9129f5a4180950d755997 Mon Sep 17 00:00:00 2001
From: Jack Yu <jack.yu@realtek.com>
Date: Tue, 15 Sep 2026 11:36:49 +0800
Subject: [PATCH] ASoC: rt721-sdca: power up the vendor analog gates
On some boards firmware leaves the RT721's vendor analog power gates
off, which the SDCA power-domain requests do not touch,
so the codec is digitally configured but analog-dead.
Program these gates in the jack/amp/mic presets, gated on a DMI quirk
table (plus a vendor_power_seq module parameter) so other RT721 boards
keep the stock behaviour.
Signed-off-by: Jack Yu <jack.yu@realtek.com>
---
sound/soc/codecs/rt721-sdca-sdw.c | 7 +++
sound/soc/codecs/rt721-sdca.c | 97 +++++++++++++++++++++++++++++++
sound/soc/codecs/rt721-sdca.h | 10 ++++
3 files changed, 114 insertions(+)
diff --git a/sound/soc/codecs/rt721-sdca-sdw.c b/sound/soc/codecs/rt721-sdca-sdw.c
index eae7d662efae..bb7c77218fdf 100644
--- a/sound/soc/codecs/rt721-sdca-sdw.c
+++ b/sound/soc/codecs/rt721-sdca-sdw.c
@@ -63,6 +63,10 @@ static bool rt721_sdca_volatile_register(struct device *dev, unsigned int reg)
static bool rt721_sdca_mbq_readable_register(struct device *dev, unsigned int reg)
{
switch (reg) {
+ case 0x010000c:
+ case 0x010000e:
+ case 0x0100011:
+ case 0x0100013:
case 0x0900004 ... 0x0900009:
case 0x0a00005:
case 0x0c00005:
@@ -80,6 +84,9 @@ static bool rt721_sdca_mbq_readable_register(struct device *dev, unsigned int re
case 0x5810039:
case 0x5b10018:
case 0x5b10019:
+ case 0x5f00000:
+ case 0x5f00020:
+ case 0x5f00030:
case 0x5f00045:
case 0x5f00048:
case 0x6100000:
diff --git a/sound/soc/codecs/rt721-sdca.c b/sound/soc/codecs/rt721-sdca.c
index a9479d0e4941..da674c026101 100644
--- a/sound/soc/codecs/rt721-sdca.c
+++ b/sound/soc/codecs/rt721-sdca.c
@@ -9,6 +9,7 @@
#include <linux/bitops.h>
#include <sound/core.h>
#include <linux/delay.h>
+#include <linux/dmi.h>
#include <linux/init.h>
#include <sound/initval.h>
#include <sound/jack.h>
@@ -140,6 +141,90 @@ static void rt721_sdca_btn_check_handler(struct work_struct *work)
pr_err_ratelimited("IO error in %s, ret %d\n", __func__, ret);
}
+static int vendor_power_seq = -1;
+module_param(vendor_power_seq, int, 0444);
+MODULE_PARM_DESC(vendor_power_seq,
+ "RT721 vendor analog power sequence: -1 = DMI match, 0 = off, 1 = on");
+
+static const struct dmi_system_id rt721_sdca_quirk_table[] = {
+ {
+ /* ASUS TUF Gaming A14 FA401EA */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "FA401EA"),
+ },
+ .driver_data = (void *)RT721_SDCA_QUIRK_VENDOR_POWER_SEQ,
+ },
+ {
+ /* MSI Claw 8 EX AI+ */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Micro-Star International Co., Ltd."),
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "MS-1T91"),
+ },
+ .driver_data = (void *)RT721_SDCA_QUIRK_VENDOR_POWER_SEQ,
+ },
+ {}
+};
+
+struct rt721_sdca_power_step {
+ u8 nid;
+ u8 reg;
+ u16 mask;
+ u16 val;
+};
+
+static const struct rt721_sdca_power_step rt721_sdca_codec_power[] = {
+ { RT721_VENDOR_ANA_CTL, RT721_MISC_POWER_CTL0, BIT(15), BIT(15) },
+ { RT721_VENDOR_ANA_CTL, RT721_MISC_POWER_CTL0, BIT(14), BIT(14) },
+ { RT721_VENDOR_ANA_CTL, RT721_MISC_POWER_CTL0, BIT(13), BIT(13) },
+ { RT721_VENDOR_ANA_CTL, RT721_MISC_POWER_CTL0, BIT(12), BIT(12) },
+ { RT721_ANA_POW_PART, RT721_ANA_POW_PART_11, BIT(15), BIT(15) },
+ { RT721_ANA_POW_PART, RT721_ANA_POW_PART_0C, BIT(15), BIT(15) },
+ { RT721_VENDOR_ANA_CTL, RT721_MISC_POWER_CTL0, BIT(3), BIT(3) },
+ { RT721_VENDOR_ANA_CTL, RT721_MISC_POWER_CTL0, BIT(10), BIT(10) },
+ { RT721_ANA_POW_PART, RT721_ANA_POW_PART_13, BIT(6), BIT(6) },
+ { RT721_ANA_POW_PART, RT721_ANA_POW_PART_0E, BIT(3), BIT(3) },
+ { RT721_VENDOR_ANA_CTL, RT721_MISC_POWER_CTL0, BIT(2), BIT(2) },
+ { RT721_VENDOR_ANA_CTL, RT721_MISC_POWER_CTL0, BIT(9), BIT(9) },
+};
+
+static void rt721_sdca_codec_analog_power(struct rt721_sdca_priv *rt721)
+{
+ size_t i;
+ int ret;
+
+ if (!(rt721->quirks & RT721_SDCA_QUIRK_VENDOR_POWER_SEQ))
+ return;
+
+ for (i = 0; i < ARRAY_SIZE(rt721_sdca_codec_power); i++) {
+ ret = rt_sdca_index_update_bits(rt721->mbq_regmap,
+ rt721_sdca_codec_power[i].nid,
+ rt721_sdca_codec_power[i].reg,
+ rt721_sdca_codec_power[i].mask,
+ rt721_sdca_codec_power[i].val);
+ if (ret)
+ dev_warn(&rt721->slave->dev,
+ "codec analog power step %zu failed: %d\n", i, ret);
+ }
+}
+
+/*
+ * Decide whether the vendor analog power sequence is needed. A module
+ * parameter forces it on or off; otherwise it is enabled only on boards in
+ * the DMI quirk table.
+ */
+static void rt721_sdca_detect_vendor_power(struct rt721_sdca_priv *rt721)
+{
+ if (vendor_power_seq == 0)
+ return;
+
+ if (vendor_power_seq > 0 || dmi_first_match(rt721_sdca_quirk_table)) {
+ rt721->quirks |= RT721_SDCA_QUIRK_VENDOR_POWER_SEQ;
+ dev_info(&rt721->slave->dev,
+ "enabling vendor analog power sequence\n");
+ }
+}
+
static void rt721_sdca_dmic_preset(struct rt721_sdca_priv *rt721)
{
rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
@@ -175,6 +260,10 @@ static void rt721_sdca_dmic_preset(struct rt721_sdca_priv *rt721)
rt_sdca_index_write(rt721->mbq_regmap, RT721_RC_CALIB_CTRL,
RT721_RC_CALIB_CTRL0, 0x0b40);
regmap_write(rt721->regmap, 0x2f5c, 0x25);
+
+ if (rt721->quirks & RT721_SDCA_QUIRK_VENDOR_POWER_SEQ)
+ rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
+ RT721_MISC_POWER_CTL30, 0xfff7);
}
static void rt721_sdca_amp_preset(struct rt721_sdca_priv *rt721)
@@ -208,6 +297,10 @@ static void rt721_sdca_amp_preset(struct rt721_sdca_priv *rt721)
SDW_SDCA_CTL(FUNC_NUM_AMP, RT721_SDCA_ENT_FU55,
RT721_SDCA_CTL_FU_MUTE, CH_02), 0x00);
regmap_write(rt721->regmap, 0x2f5d, 0x1);
+
+ if (rt721->quirks & RT721_SDCA_QUIRK_VENDOR_POWER_SEQ)
+ rt_sdca_index_write(rt721->mbq_regmap, RT721_VENDOR_ANA_CTL,
+ RT721_MISC_POWER_CTL20, 0xfff7);
}
static void rt721_sdca_jack_preset(struct rt721_sdca_priv *rt721)
@@ -287,6 +380,8 @@ static void rt721_sdca_jack_preset(struct rt721_sdca_priv *rt721)
regmap_write(rt721->regmap, 0x2f51, 0x00);
rt_sdca_index_write(rt721->mbq_regmap, RT721_HDA_SDCA_FLOAT,
RT721_MISC_CTL, 0x0004);
+
+ rt721_sdca_codec_analog_power(rt721);
}
static void rt721_sdca_jack_init(struct rt721_sdca_priv *rt721)
@@ -1472,6 +1567,8 @@ int rt721_sdca_init(struct device *dev, struct regmap *regmap,
rt721->regmap = regmap;
rt721->mbq_regmap = mbq_regmap;
+ rt721_sdca_detect_vendor_power(rt721);
+
regcache_cache_only(rt721->regmap, true);
regcache_cache_only(rt721->mbq_regmap, true);
diff --git a/sound/soc/codecs/rt721-sdca.h b/sound/soc/codecs/rt721-sdca.h
index 24ce188562ba..d6879018d3b3 100644
--- a/sound/soc/codecs/rt721-sdca.h
+++ b/sound/soc/codecs/rt721-sdca.h
@@ -21,6 +21,7 @@ struct rt721_sdca_priv {
struct snd_soc_component *component;
struct sdw_slave *slave;
struct sdw_bus_params params;
+ unsigned long quirks;
bool hw_init;
bool first_hw_init;
struct mutex calibrate_mutex;
@@ -74,6 +75,10 @@ struct rt721_sdca_dmic_kctrl_priv {
#define RT721_MBIAS_LV_CTRL2 0x07
#define RT721_VREF1_HV_CTRL1 0x0a
#define RT721_VREF2_LV_CTRL1 0x0b
+#define RT721_ANA_POW_PART_0C 0x0c
+#define RT721_ANA_POW_PART_0E 0x0e
+#define RT721_ANA_POW_PART_11 0x11
+#define RT721_ANA_POW_PART_13 0x13
/* Index (NID:04h) */
#define RT721_DAC_2CH_CTRL3 0x02
@@ -127,6 +132,8 @@ struct rt721_sdca_dmic_kctrl_priv {
/* Index (NID:5fh) */
#define RT721_MISC_POWER_CTL0 0x00
+#define RT721_MISC_POWER_CTL20 0x20
+#define RT721_MISC_POWER_CTL30 0x30
#define RT721_MISC_POWER_CTL31 0x31
#define RT721_UAJ_TOP_TCON13 0x44
#define RT721_UAJ_TOP_TCON14 0x45
@@ -268,6 +275,9 @@ enum {
RT721_AIFS,
};
+/* quirks */
+#define RT721_SDCA_QUIRK_VENDOR_POWER_SEQ BIT(0)
+
int rt721_sdca_io_init(struct device *dev, struct sdw_slave *slave);
int rt721_sdca_init(struct device *dev, struct regmap *regmap,
struct regmap *mbq_regmap, struct sdw_slave *slave);
--
2.54.0
Hi Jack, I tested the patch you sent on my affected ASUS TUF Gaming A14 FA401EA. The result is very promising: the patch fixes both the internal speakers and the internal SoundWire microphones. Test kernel: 7.3.0-rc2-fa401ea-jack-v1+ with your patch: ASoC: rt721-sdca: power up the vendor analog gates Results: Internal speakers: FIXED Internal SoundWire microphones: FIXED Headphone jack detection: still not working Headphone playback: still not working I verified the internal microphones in Audacity and they now record normally. The remaining headphone issue appears to involve more than just automatic switching. With headphones physically inserted, wpctl status is identical to the state with the headphones disconnected. The ALSA jack controls also remain: Headphone Jack = off Headset Mic Jack = off I ran: `sudo alsactl monitor` and inserted/removed the headphone plug multiple times. No events were generated at all. I also tried forcing the headphone playback path manually. The relevant mixer controls initially showed: Headphone Switch = off Speaker Switch = on I forced: amixer -c amdsoundwire cset numid=9 1 amixer -c amdsoundwire cset numid=13 0 which resulted in: Headphone Switch = on Speaker Switch = off Then I explicitly sent audio to the PipeWire headphone sink: pw-play --target 58 /usr/share/sounds/alsa/Front_Center.wav and also tested another WAV file. There was still no sound from the headphones. Therefore, on this FA401EA the current patch successfully fixes the analog power-up needed for the speakers and internal microphones, but the headphone path still appears to have two remaining problems: Headphone/headset jack insertion is not detected/reported. The headphone playback path remains silent even when Headphone Switch is manually forced on and audio is explicitly routed to the headphone sink. I have attached a dmesg log filtered for RT721/SoundWire/jack/headphone-related messages after booting with your patch. The laptop is still running BIOS FA401EA.304, the latest available firmware for this model. Please let me know what registers or additional diagnostics you would like me to capture for the headphone/jack path. I am happy to continue testing patches or register dumps on this unit. Thanks, Cristian On Tue, Sep 15, 2026 at 6:44 AM Jack Yu <jack.yu@realtek.com> wrote: > > Hi Cristian, > > Could you check if the attached patch fix the issue? > Thanks. > > Regards, > Jack > > > -----Original Message----- > > From: Cristian Timohi <cristiantimohi@gmail.com> > > Sent: Tuesday, September 15, 2026 2:52 AM > > To: Mark Brown <broonie@kernel.org> > > Cc: Shengyu Qu <wiagn233@outlook.com>; Jack Yu <jack.yu@realtek.com>; > > Syed Saba Kareem <syed.sabakareem@amd.com>; Mukunda,Vijendar > > <vijendar.mukunda@amd.com>; Flove(HsinFu) <flove@realtek.com>; > > venkataprasad.potturu@amd.com; linux-sound@vger.kernel.org; Oder Chiou > > <oder_chiou@realtek.com>; vkoul@kernel.org; > > yung-chuan.liao@linux.intel.com; pierre-louis.bossart@linux.dev; > > lgirdwood@gmail.com; linux-kernel@vger.kernel.org; Dommati, Sunil-kumar > > <Sunil-kumar.Dommati@amd.com>; Fish690103 <fish690103@realtek.com>; > > Mike Lin (林曉能) <mikelin@realtek.com> > > Subject: Re: [BUG] ASoC/AMD ACP70/RT721: ASUS TUF Gaming A14 FA401EA > > speakers silent and headphone jack buzzes on playback > > > > > > External mail : This email originated from outside the organization. Do not > > reply, click links, or open attachments unless you recognize the sender and > > know the content is safe. > > > > > > > > Hi Mark, Jack, Shengyu, all, > > > > I performed the test Jack requested for NID 0x5f / index 0x30 on my affected > > ASUS TUF Gaming A14 FA401EA. > > > > I am including all details below because there were a few important > > observations during the test. > > > > One note before the technical details: I am not a Linux kernel/audio developer, > > and this level of ASoC/SoundWire/RT721 debugging is beyond my normal area > > of expertise. I am working through these tests with ChatGPT helping me > > understand the driver code, build temporary diagnostic modules, and perform > > the tests carefully. > > > > I am trying to keep every experiment minimal, reversible, and verified by > > readback where possible. I hope the results are still useful for debugging the > > actual issue. > > > > --- > > > > ## SYSTEM > > > > Laptop: > > ASUS TUF Gaming A14 FA401EA > > > > CPU/platform: > > Ryzen AI MAX+ 392 > > AMD ACP 7.0 > > > > Codec: > > Realtek RT721 SDCA > > > > BIOS: > > FA401EA.304 > > > > This machine is already running the latest firmware/BIOS currently available > > for the FA401EA. Therefore, at least on this unit, the issue is reproducible with > > the latest available ASUS firmware installed. > > > > Running kernel: > > 7.3.0-rc2-fa401ea-rt721+ > > > > Kernel source tree HEAD: > > 1a3fdcb408 ASoC: rt721-sdca: Adjust latency control to fix no-sound issue > > > > This includes the a20afec40ea1 fix. > > > > The following patch was NOT present during this test: > > > > ASoC: rt721-sdca: Update preset for all functions > > > > Audio card: > > > > amd-soundwire > > ASUSTeKCOMPUTERINC.-TUFGamingA14FA401EA-1.0-FA401EA > > > > SmartMic capture PCM: > > > > card: amdsoundwire > > device 4: SDW1-PIN5-CAPTURE-SmartMic > > DAI: rt721-sdca-aif3-4 > > > > --- > > > > ## DIAGNOSTIC MODULE > > > > I built a temporary out-of-tree snd-soc-rt721-sdca module matching the > > running kernel. > > > > No DKMS installation was performed and no permanent module replacement > > was made. > > > > The temporary module initially only did the following: > > > > 1. Added MBQ address 0x5f00030 to the readable and volatile register lists. > > > > 2. Added rt_sdca_index_read() calls inside: > > > > rt721_sdca_pde11_event() > > > > to read: > > > > NID: 0x5f > > index: 0x30 > > > > at three points: > > > > * before requesting mic-path PS0 > > * after requesting mic-path PS0 > > * before requesting PS3 > > > > The existing PDE2A power-state request itself was left unchanged. > > > > --- > > > > ## BASELINE READ-ONLY TEST > > > > Before capture I enabled: > > > > rt721 FU1E Capture Switch = on,on,on,on > > > > Capture command: > > > > arecord -D hw:amdsoundwire,4 > > -f S16_LE > > -r 48000 > > -c 2 > > -d 3 > > /tmp/rt721-mic-test.wav > > > > The register values were: > > > > RT721TEST mic 5f:30 before PS0: 0xffb7 > > RT721TEST mic 5f:30 after PS0: 0xffb7 > > RT721TEST mic 5f:30 before PS3: 0xffb7 > > > > Therefore, on my affected FA401EA: > > > > 0x5f:0x30 = 0xffb7 > > > > and requesting PDE2A PS0 does NOT change it. > > > > I then analyzed the raw PCM samples. > > > > Capture: > > > > 144000 frames > > 48000 Hz > > stereo > > S16_LE > > 3 seconds > > > > Channel 0: > > > > min=0 > > max=0 > > RMS=0.00 > > nonzero samples=0/144000 > > nonzero percentage=0.00% > > distinct sample values=1 > > > > Channel 1: > > > > min=0 > > max=0 > > RMS=0.00 > > nonzero samples=0/144000 > > nonzero percentage=0.00% > > distinct sample values=1 > > > > So the SmartMic capture is exact digital zero on both channels. > > > > --- > > > > ## 0xFFB7 VS 0xFFF7 > > > > Jack mentioned that the default value according to the RT721 specification for: > > > > NID 0x5f > > index 0x30 > > > > is: > > > > 0xfff7 > > > > My hardware returns: > > > > 0xffb7 > > > > Difference: > > > > 0xfff7 > > 0xffb7 > > ------ > > > > 0x0040 > > > > So BIT(6) is the only difference between the value observed on my unit and > > 0xfff7. > > > > --- > > > > ## FIRST ATTEMPT TO FORCE BIT(6) > > > > I then modified the temporary module to set only BIT(6) using: > > > > rt_sdca_index_update_bits(..., BIT(6), BIT(6)) > > > > rather than overwriting the entire register. > > > > This should change: > > > > 0xffb7 -> 0xfff7 > > > > In the first attempt I performed this before requesting PS0. > > > > That attempt failed safely: > > > > RT721TEST mic 5f:30 before PS0: read failed: -16 RT721TEST force BIT6 failed: > > -16 > > > > -16 is EBUSY. > > > > Since rt_sdca_index_update_bits() first reads the register and returns > > immediately if the read fails, no register write occurred during this first > > attempt. > > > > After PS0 the register became readable and still contained: > > > > 0xffb7 > > > > There was also a runtime PM issue during this attempt: > > > > runtime PM trying to activate child device sdw:0:1:025d:0721:01 but parent > > (sdw-master-0-1) is not active > > > > followed by: > > > > Failed to resume device: -61 > > Slave 1 alert handling failed: -61 > > > > Because of this I did not consider the first attempt authoritative. > > > > --- > > > > ## FINAL CONTROLLED TEST > > > > For the second attempt I moved the BIT(6) update until AFTER PDE2A had been > > requested to PS0. > > > > I also explicitly kept the complete relevant path runtime-active during the > > experiment. > > > > ACP PCI device: > > > > /sys/bus/pci/devices/0000:64:00.5 > > > > SoundWire manager: > > > > /sys/devices/pci0000:00/0000:00:08.1/0000:64:00.5/amd_sdw_manager.1 > > > > RT721 codec: > > > > /sys/bus/soundwire/devices/sdw:0:1:025d:0721:01 > > > > For all three: > > > > power/control = on > > runtime_status = active > > > > PipeWire, WirePlumber and alsa-state were stopped during the experiment so > > nothing else held the ALSA devices. > > > > RT721 status before capture: > > > > Attached > > > > The sequence inside rt721_sdca_pde11_event() was: > > > > 1. Read 0x5f:0x30 > > 2. Request PDE2A PS0 > > 3. Wait 10-20 ms > > 4. Read 0x5f:0x30 again > > 5. Set only BIT(6) > > 6. Read 0x5f:0x30 again to verify the write 7. Perform SmartMic capture 8. > > Read 0x5f:0x30 before PS3 9. Clear BIT(6) again 10. Read back the register to > > verify restoration 11. Request PS3 > > > > The resulting kernel log was: > > > > RT721_BIT6_V2_BEGIN > > > > RT721TEST mic 5f:30 before PS0: 0xffb7 > > RT721TEST mic 5f:30 after PS0: 0xffb7 > > RT721TEST mic 5f:30 after BIT6 set: 0xfff7 RT721TEST mic 5f:30 before PS3: > > 0xfff7 RT721TEST mic 5f:30 after BIT6 restore: 0xffb7 > > > > RT721_BIT6_V2_END > > > > So the requested value was successfully written and verified by hardware > > readback. > > > > During the entire three-second capture: > > > > 0x5f:0x30 = 0xfff7 > > > > After capture, BIT(6) was cleared again and readback confirmed that the > > original value was restored: > > > > 0x5f:0x30 = 0xffb7 > > > > --- > > > > ## CAPTURE RESULT WITH 0x5F:0x30 = 0xFFF7 > > > > Capture command: > > > > arecord -D hw:amdsoundwire,4 > > -f S16_LE > > -r 48000 > > -c 2 > > -d 3 > > /tmp/rt721-mic-bit6-v2.wav > > > > Capture: > > > > 144000 frames > > 48000 Hz > > stereo > > S16_LE > > > > Channel 0: > > > > min=0 > > max=0 > > RMS=0.00 > > nonzero samples=0/144000 > > nonzero percentage=0.00% > > distinct sample values=1 > > > > Channel 1: > > > > min=0 > > max=0 > > RMS=0.00 > > nonzero samples=0/144000 > > nonzero percentage=0.00% > > distinct sample values=1 > > > > Therefore the microphone capture remained exact digital zero on both > > channels even while 0x5f:0x30 was verified to be 0xfff7. > > > > --- > > > > ## SUMMARY > > > > Firmware: > > > > BIOS FA401EA.304 > > Latest currently available firmware for FA401EA Issue still reproducible > > > > Baseline: > > > > 0x5f:0x30 = 0xffb7 > > DMIC = exact digital zero > > > > Normal PDE2A -> PS0: > > > > 0x5f:0x30 remains 0xffb7 > > > > Explicit BIT(6) set: > > > > 0x5f:0x30 becomes 0xfff7 > > hardware readback confirms 0xfff7 > > > > SmartMic capture while register is 0xfff7: > > > > Channel 0 = exact digital zero > > Channel 1 = exact digital zero > > > > After capture: > > > > BIT(6) cleared > > 0x5f:0x30 returns to 0xffb7 > > > > --- > > > > ## CONCLUSION > > > > On my affected FA401EA, explicitly setting NID 0x5f / index 0x30 to the > > specification default value 0xfff7 is NOT sufficient to make the microphones > > work. > > > > The machine is already running BIOS FA401EA.304, which is the latest > > firmware currently available for this model, and the issue is still reproducible. > > Therefore there is no newer ASUS firmware currently available for me to test > > against this behavior. > > > > One interesting difference from the earlier reported register dump is that my > > unit does not currently show 0x01c2 at 0x5f:0x30. > > > > It shows: > > > > 0xffb7 > > > > both before and after the normal PDE2A PS0 request. > > > > The only difference from the documented default value 0xfff7 is BIT(6). > > > > However, setting BIT(6), verifying 0xfff7 by hardware readback, and keeping > > that value for the entire capture still leaves both microphone channels > > producing exact digital zeros. > > > > This seems to suggest that some other part of the analog/vendor power > > sequence is still required. > > > > This could also explain why the community workaround which writes several > > RT721 vendor analog power registers succeeds: that workaround modifies > > considerably more than 0x5f:0x30, including codec-wide power state at > > 0x5f:0x00 and other analog power registers. > > > > I intentionally did NOT apply the complete vendor power sequence during this > > test because I wanted to test Jack's 0x5f:0x30 question independently and > > provide a clean result. > > > > For reference, the internal speakers also remain completely silent on this > > machine with a20afec40ea1 alone, as previously reported. > > > > If you would like me to perform another targeted test, please specify the exact > > register/value and at what state it should be read or written, and I will try to > > reproduce it carefully. > > > > Again, I am not experienced with Linux audio driver development and I am > > relying on ChatGPT to help me understand the kernel code and construct these > > diagnostic tests. I wanted to be transparent about that. > > > > Nevertheless, I have tried to keep the experiments minimal and reversible and > > to verify register changes by hardware readback wherever possible. > > > > I hope these results help narrow down the issue. > > > > Thanks, > > Cristian > > > > > > On Mon, Sep 14, 2026 at 9:13 PM Mark Brown <broonie@kernel.org> wrote: > > > > > > On Mon, Sep 14, 2026 at 08:16:22PM +0800, Shengyu Qu wrote: > > > > > > > On my FA401EA this issue doesn't exist so I can't test. Maybe you > > > > can ask at bugzilla so other users with this issue could test? > > > > > > > PS: maybe this is the issue for some old batches of RT721 chip? My > > > > device is very new and this might be why I don't have this issue? > > > > > > Could some firmware update have done something that helps somehow? [ 0.000000] Linux version 7.3.0-rc2-fa401ea-jack-v1+ (chris@Chris-Laptop) (gcc (GCC) 16.2.1 20260819 (Red Hat 16.2.1-2), GNU ld version 2.47.20260726) #2 SMP PREEMPT_DYNAMIC Tue Sep 15 21:31:03 EEST 2026 [ 0.000000] Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-7.3.0-rc2-fa401ea-jack-v1+ root=UUID=81a48559-edf6-4b0b-96cd-1cb39dbcb77a ro rootflags=subvol=root rhgb quiet [ 0.039910] Kernel command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-7.3.0-rc2-fa401ea-jack-v1+ root=UUID=81a48559-edf6-4b0b-96cd-1cb39dbcb77a ro rootflags=subvol=root rhgb quiet [ 1.674003] usb usb1: Manufacturer: Linux 7.3.0-rc2-fa401ea-jack-v1+ xhci-hcd [ 1.674924] usb usb2: Manufacturer: Linux 7.3.0-rc2-fa401ea-jack-v1+ xhci-hcd [ 1.676681] usb usb3: Manufacturer: Linux 7.3.0-rc2-fa401ea-jack-v1+ xhci-hcd [ 1.679174] usb usb4: Manufacturer: Linux 7.3.0-rc2-fa401ea-jack-v1+ xhci-hcd [ 1.681472] usb usb5: Manufacturer: Linux 7.3.0-rc2-fa401ea-jack-v1+ xhci-hcd [ 1.682339] usb usb6: Manufacturer: Linux 7.3.0-rc2-fa401ea-jack-v1+ xhci-hcd [ 1.684206] usb usb7: Manufacturer: Linux 7.3.0-rc2-fa401ea-jack-v1+ xhci-hcd [ 1.684966] usb usb8: Manufacturer: Linux 7.3.0-rc2-fa401ea-jack-v1+ xhci-hcd [ 8.206709] rt721-sdca sdw:0:1:025d:0721:01: enabling vendor analog power sequence [ 8.212385] input: amd-soundwire Headset Jack as /devices/pci0000:00/0000:00:08.1/0000:64:00.5/amd_sdw/sound/card1/input22
© 2016 - 2026 Red Hat, Inc.