ALC295 internal DMIC: works only after a warm reboot from Windows, and no readable state differs

Hi!

I have spent several days on the internal digital microphone of a
Lenovo ThinkPad
X1 Tablet 3rd gen (20KJ/20KK, ALC295, PCI SSID 17aa:2244) and have reached
a result I cannot explain. I am writing partly to ask, and partly because
the eliminations may save someone else the time.

The symptom, and the switch:

- Cold boot Linux: the internal mic captures a floating analog input. Not
audio.
- Boot Windows, let it reach the desktop, then warm-reboot into Linux: the same
stock kernel, the same driver, the same registers, and the mic records real
audio. Verified by a commercial acoustic-fingerprinting service returning
the correct track from room audio, not by level alone.
- Power-cycle: dead again. One Windows boot per power cycle, not per reboot.

The state is remarkably durable. It survives S3 suspend, the codec's
own D3 power-down,
FUNCTION_RESET, a full PCI remove-and-rescan, a complete DSP core reset,
and any number of Linux-to-Linux warm reboots. Hibernation kills it, and so
does about 30 seconds unplugged, so it is not stored charge.

What I cannot find is any difference between the two states:

- ~2400 codec registers across all eight vendor COEF banks: nothing
separates working from dead. The two *working* samples I have differ from
each other more than either differs from a dead one.
- The codec verb interface replayed as static state, and separately as
the exact
Windows CORB burst in true ring order with read-backs in place, the resulting
state verified still live afterwards: still dead.
- The full 16 KiB HD-audio controller BAR0: byte-identical, after masking seven
known free-running registers. LCTL/SCF is 2 in every state under both operating
systems.
- 152 pinctrl pads, PCI config space, ACPI, the clock tree: identical.
- All four PCH GPIO communities, read raw through /dev/mem, including
the deep-well
GPD community at fdad0000, which PNP0C02 claims and pinctrl never binds, so
no pinctrl-based capture had ever covered those 12 pads: md5-identical.
- The PMC and the EC: identical, or explained (the EC delta decodes
via the DSDT
to charger and power-budget fields).

Two things I did establish that may be the useful part:

1. Windows does not use the PDM/DMIC interface at all. I decoded its DSP
IPC for one capture-open, and the gateway is HDA_LINK_INPUT (dma_type 9),
not DMIC_LINK_INPUT. The mic audio comes over the HD-audio link from the
codec - the same source the legacy path already uses. Linux, on a working
boot, captures it with PPCTL = 0, i.e. with the DSP processing pipe
globally disabled, while Windows idles at 0xc00003c1.

2. RTKVHD64.sys is necessary but its codec verbs are not the
mechanism. Disabling
only the Realtek codec function driver in Windows, leaving the controller
and DSP running, and then warm-rebooting, leaves the mic dead. Disabling
the whole controller: also dead. So the Windows audio stack is a genuine
prerequisite and firmware/BIOS acting alone is excluded, but the verbs that
driver issues, replayed exactly, do nothing.

So: something survives a full codec re-initialisation and a full DSP reset,
persists across arbitrary warm reboots, dies within seconds of power
removal,
and is invisible in every register on this platform I have found a way to
read.

My questions, in the order I would most value an answer:

- Is there state on an ALC295 that is not reachable through the verb or
COEF interfaces and that clears only on VDD loss? Everything I see fits a
latch inside the codec that the documented interface cannot read back.
- What can the vendor driver do to this codec that is neither a codec verb nor
DSP-resident state? On this platform the codec enumerates on the SST bus
(INTELAUDIO\FUNC_01), so it also speaks DSP IPC — but I reset the DSP core
out from under a working state and the mic kept working, so the libraries
it loads are not it either.
- Has anyone seen this shape before, on any device? A Windows boot
arming something
for the rest of the power cycle, with no readable state delta.

Everything, including the tools and the negative results, is written up
here:

https://github.com/sandbranch/x1-tablet-gen3-microphone

I should say plainly that I am not asking anyone to fix this. I have a
switchable
A/B on this machine - Windows warm boot on, power cycle off - so if anyone
wants a specific register read, a specific write tried, or a trace captured
in either state, it is cheap and I can usually turn it around the same
day. That offer is the main reason I am writing.

There is no quirk for 17aa:2244 anywhere in the Realtek codec tree; I
checked the source rather than assuming. The same symptom is reported and
unresolved for this model on Fedora (Discussion #159185) and Linux Mint
(t=450783, including a second machine in that thread), so it is not a fault
in my unit.

Thanks for reading this far, and for ALSA (!),
David Sandquist