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
next prev parent 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®