Re: [BUG] hda/conexant: SN6140 (0x14f11f87) loses wi dget state across suspend — silent capture + dead speaker, no resume callback

Follow-up with three weeks of monitoring data (a watchdog samples the ALSA
PCM state every 5s and snapshots context on each failure), plus a specific
question for Bo Liu about the codec's internal power behaviour.

== New findings since the original report ==

1. The failures are NOT limited to suspend/resume. Of ~30 logged events,
roughly half occurred with no suspend at all — typically on the first
capture after 1-3 h of capture-idle, and occasionally mid-stream (hw_ptr
advancing, then frozen). A resume-only fix therefore would not cover all
cases.

2. In the failed state the widgets read "Power: setting=D3, actual=D3" —
i.e. the codec's power-state register itself holds D3 as the *set* value —
while on the software side nobody requested it:
- snd_hda_intel power_save=0 power_save_controller=N (verified live),
- kernel log completely silent at the moment of failure,
- PCI device and codec stay in D0 / runtime-active,
- userspace (PipeWire/WirePlumber) ruled out.
Codec re-init via /sys/.../reconfig always restores the silent variant;
the spurious-response/single_cmd variant needs a controller reset (reboot).

3. Event frequency wanders (0-6/day) and has worsened over the three weeks,
independent of kernel (6.17.0-122035 → 6.17.0-124040), PipeWire and other
userspace changes — so a platform/firmware factor may be involved. An
EC/BIOS update recommended by the vendor (TUXEDO) is pending on our side;
I will report its effect on the thread.

== Question for Bo Liu ==

Does the SN61xx family implement an internal / autonomous power-down (or
power-state controller) that is meant to be configured or disabled through
vendor init verbs? The observed behaviour — widgets ending up with
setting=D3 with no driver activity, recoverable only by re-running codec
init — looks like un-configured codec-internal power logic rather than
driver-initiated PM.

Your SN6186 work adds senary_init_verb() and an init-verb/fixup framework.
Does the SN6140 need an equivalent vendor init-verb table, and could you
share the appropriate verbs/coefficients? (conexant.c already writes one
vendor coefficient for this family — the 0x320/0x010 micbias comparator
setting on nid 0x1c — so I assume more such coefs exist.)

== Candidate patch, and offer to test ==

I drafted a minimal resume callback for conexant.c mirroring the pending
senarytech one (below). It builds and loads fine on 6.17, but per finding
(1) it cannot address the no-suspend cases, so I have reverted it pending
your guidance on the init-verb question. I have a ready build/test pipeline
for this machine and can turn any test patch around within a day.

--- a/sound/hda/codecs/conexant.c
+++ b/sound/hda/codecs/conexant.c
@@ -1269,6 +1269,21 @@
return err;
}

+/*
+ * The generic HDA resume path restores the register cache but does not
re-run
+ * the codec's init sequence, so vendor-specific hardware state (widget
power,
+ * converter/pin setup) can be lost after S3 resume, leaving capture and
the
+ * internal speaker silent with the codec stuck in D3. Mirror the
senarytech
+ * fix: on resume, re-sync the register cache, re-run init, and resync
jacks.
+ */
+static int cx_resume(struct hda_codec *codec)
+{
+ regcache_sync(codec->core.regmap);
+ cx_init(codec);
+ snd_hda_jack_report_sync(codec);
+ return 0;
+}
+
static const struct hda_codec_ops cx_codec_ops = {
.probe = cx_probe,
.remove = cx_remove,
@@ -1277,6 +1292,7 @@
.init = cx_init,
.unsol_event = snd_hda_jack_unsol_event,
.suspend = cx_suspend,
+ .resume = cx_resume,
.check_power_status = snd_hda_gen_check_power_status,
.stream_pm = snd_hda_gen_stream_pm,
};

Thanks,
Attila Hudecz

On Thu, Jul 30, 2026 10:14 AM, Attila Hudecz <[email protected]> wrote:

> Hi,
>
> Conexant SN6140 (patch_conexant) intermittently ends up with its Audio
> Function
> Group and widgets in D3 after system suspend/resume (and after long idle),
> while
> ALSA still treats the stream as RUNNING. Result: the internal mic records
> digital
> silence and the internal speaker is dead (same codec drives both). The
> kernel
> logs nothing at the moment of failure. Writing to
> /sys/class/sound/hwCxDy/reconfig (full codec re-init) reliably restores
> it; a
> userspace (PipeWire) restart does not.
>
> This looks like the same S3/resume state-restoration weakness that was
> recently
> addressed for the sibling Senarytech SN6186 in the new patch_senary driver
> (resume callback that re-syncs regcache, re-applies init verbs, and resets
> the
> bus). That fix does not exist on the patch_conexant / SN6140 path. Could
> the same
> resume handling be added for SN6140?
>
> == Hardware / software ==
>
> - Machine: TUXEDO InfinityBook Pro AMD Gen10, BIOS N.1.20A13
> - SoC: AMD Ryzen AI 9 365 (Strix Point)
> - HDA controller: AMD Ryzen HD Audio [1022:15e3] @ PCI 0000:65:00.6
> - Codec: Conexant SN6140
> Vendor Id 0x14f11f87
> Subsystem Id 0x1d053012
> Revision Id 0x100100
> - Driver: snd_hda_codec_conexant (patch_conexant)
> - Kernel: 6.17.0-122035-tuxedo (Ubuntu / TUXEDO OS 24.04)
> - ALSA: k6.17.0-122035-tuxedo
> - Note: the AMD ACP digital-mic path is unavailable on this machine
> (acp_asoc_acp70.0: warning: No matching ASoC machine driver found), so
> this HDA
> codec is the only capture path -- a wedge leaves the laptop with no audio.
>
> == Failed state ==
>
> During an active capture (ALSA state: RUNNING):
>
> - Audio Function Group and widgets read Power: setting=D3, actual=D3,
> including
> the audio output (NID 0x11), the ADC (NID 0x13), the vendor widget (0x15)
> and
> the pins (0x16/0x17/0x1a). The mic pin 0x1a has Pin-ctls: 0x00 (input off).
> - The capture converter NID 0x13 has no stream tag (stream=0).
> - /proc/asound/cardX/pcm0c/sub0/status: state: RUNNING but hw_ptr never
> advances;
> recordings are 44-byte (header-only) WAVs; arecord -D hw:1,0 returns
> Input/output error.
> - Playback side is symmetric: pcm0p hw_ptr advances while output widgets
> sit in
> D3 -- the stack "plays" into a powered-down output stage.
> - Crucially, the codec device stays active/D0 (PCI power_state D0, hdaudio
> power/control on) -- it is widget-level power that is not restored, not a
> whole-codec runtime suspend.
>
> snd_hda_intel power_save=0 power_save_controller=N is set and verified
> live and
> does not prevent it -- consistent with this being the suspend/resume path
> rather
> than runtime PM.
>
> == The one "loud" occurrence (points at suspend entry) ==
>
> Usually the failure is silent, but once it produced errors 1.06s after
> PM: suspend entry (s2idle):
>
> azx_get_response timeout, switching to polling mode: last cmd=0x01670c00
> No response from codec, disabling MSI: last cmd=0x01670c00
> azx_get_response timeout, switching to single_cmd mode: last cmd=0x01670c00
>
> last cmd=0x01670c00 = Set EAPD/BTL Enable=0 on pin 0x16 (HP pin, per the
> codec
> auto-probe hp_outs=1 (0x16)) -- i.e. the codec stopped responding while
> its amp
> was being powered down entering suspend, then dropped to single_cmd mode.
> This
> matches the in-code comment in the Senarytech submission
> (
> https://www.google.com/url?q=https://patchew.org/linux/[email protected]/&source=gmail&ust=1785485315190000&sa=E
> ):
> "Some laptops with Senary chips show stalls in S3 resume, which falls into
> the
> single-cmd mode. Better to make reset, then."
>
> == Frequency / pattern (18 occurrences over ~11 days, monitored) ==
>
> - ~1-3 per day; 56% occur 06:00-09:00 (first capture after overnight
> suspend/idle).
> - 17 of 18 are "capture never started" (hw_ptr=0 at open) -- i.e. the
> codec was
> already in the bad state before the stream opened; 1 was a mid-stream
> stall.
> - Recovery via reconfig verified repeatedly (real audio, RMS>0, after).
>
> == What recovers it ==
>
> Writing 1 to /sys/class/sound/hwCxDy/reconfig (after releasing the device)
> triggers hda-codec: reconfiguring + the normal SN6140 auto-probe and fully
> restores both mic and speaker. This is effectively a manual version of the
> resume-callback re-init the SN6186 path now performs.
>
> == Request ==
>
> Please consider adding S3 resume handling for the Conexant SN6140 in
> patch_conexant equivalent to the SN6186 work in patch_senary:
> - resume callback: regcache re-sync + re-apply init verbs + re-report jack
> state
> (
> https://www.google.com/url?q=https://lkml.iu.edu/hypermail/linux/kernel/2603.0/07887.html&source=gmail&ust=1785485315191000&sa=E
> ),
> - init-verb / fixup framework
> (
> https://www.google.com/url?q=https://lkml.iu.edu/hypermail/linux/kernel/2603.0/07886.html&source=gmail&ust=1785485315191000&sa=E
> ),
> - bus reset on the single_cmd stall.
>
> I can provide full dmesg, codec#0 dumps in both healthy and failed states,
> raw
> HDA-verb read/write transcripts, and timestamped monitor logs, and I'm
> happy to
> test patches on this hardware.
>
> Thanks,
> Attila Hudecz
>