mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jack Yu <jack.yu@realtek.com>
To: Cristian Timohi <cristiantimohi@gmail.com>,
	Mark Brown <broonie@kernel.org>
Cc: "Shengyu Qu" <wiagn233@outlook.com>,
	"Syed Saba Kareem" <syed.sabakareem@amd.com>,
	"Mukunda,Vijendar" <vijendar.mukunda@amd.com>,
	"Flove(HsinFu)" <flove@realtek.com>,
	"venkataprasad.potturu@amd.com" <venkataprasad.potturu@amd.com>,
	"linux-sound@vger.kernel.org" <linux-sound@vger.kernel.org>,
	"Oder Chiou" <oder_chiou@realtek.com>,
	"vkoul@kernel.org" <vkoul@kernel.org>,
	"yung-chuan.liao@linux.intel.com"
	<yung-chuan.liao@linux.intel.com>,
	"pierre-louis.bossart@linux.dev" <pierre-louis.bossart@linux.dev>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"linux-kernel@vger.kernel.org" <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
Date: Tue, 15 Sep 2026 03:44:11 +0000	[thread overview]
Message-ID: <a61ca5276d914235808711d7935e0f3e@realtek.com> (raw)
In-Reply-To: <CAAAbPi5fkpV3V1Ju+RYFOHWqNO+KjwoRVXnDgamNL5DVG0rbzA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 11943 bytes --]

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?

[-- Attachment #2: 0001-ASoC-rt721-sdca-power-up-the-vendor-analog-gates.patch --]
[-- Type: application/octet-stream, Size: 8056 bytes --]

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


  reply	other threads:[~2026-09-15  3:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 16:43 Cristian Timohi
2026-09-03  5:41 ` Mukunda,Vijendar
2026-09-03  8:40   ` Syed Saba Kareem
2026-09-04  6:00     ` Jack Yu
2026-09-08 20:49       ` Cristian Timohi
2026-09-09  8:21         ` Jack Yu
2026-09-09 18:53           ` Cristian Timohi
2026-09-12  5:46           ` Shengyu Qu
2026-09-14  9:44             ` Jack Yu
2026-09-14 12:16               ` Shengyu Qu
2026-09-14 18:13                 ` Mark Brown
2026-09-14 18:52                   ` Cristian Timohi
2026-09-15  3:44                     ` Jack Yu [this message]
2026-09-15 19:05                       ` Cristian Timohi

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=a61ca5276d914235808711d7935e0f3e@realtek.com \
    --to=jack.yu@realtek.com \
    --cc=Sunil-kumar.Dommati@amd.com \
    --cc=broonie@kernel.org \
    --cc=cristiantimohi@gmail.com \
    --cc=fish690103@realtek.com \
    --cc=flove@realtek.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=mikelin@realtek.com \
    --cc=oder_chiou@realtek.com \
    --cc=pierre-louis.bossart@linux.dev \
    --cc=syed.sabakareem@amd.com \
    --cc=venkataprasad.potturu@amd.com \
    --cc=vijendar.mukunda@amd.com \
    --cc=vkoul@kernel.org \
    --cc=wiagn233@outlook.com \
    --cc=yung-chuan.liao@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®