M3: the sound card binds (2026-11-04, 11:32 PM EST)
Attempts 2026-11-04-26, -27 and -28, M3 ticket 10 (.scratch/m3-rootfs/issues/10-audio-attempt.md), task #19. TEST
IMAGES with GBOOK_DTS_EXTRA=dts/diag/sound.dtsi: kernels #30 (g7072998+, image 5e59c669…), #31 (ge8c45c0,
c701044f…) and #32 (gc613c1d, 2947943c…); rootfs c1646b8a… (snapshot 20261104T000000Z, 321 packages) on ROOT
for all three. Sources: dumps/firstboot/2026-11-04-netlog.txt boots #24 to #26, 2026-11-04-ap.log, the m3-*
captures (both gitignored); attempt.sh tally '^2026-11-04-2[678]$': boots=3 clean=3 stalled=0, all cold starts.
Result
aplay -l on boot -28: card 0: X1E80100DellXPS [X1E80100-Dell-XPS-13-9345], device 1: MultiMedia2 Playback;
arecord -l: device 3: MultiMedia4 Capture; alsaucm listcards: 0: hw:0 X1E80100-Dell-XPS-13-9345 (Debian’s Dell
XPS 13 9345 profile resolves through the link rootfs/customize.sh adds). No audio device in any deferred read, no
tplg firmware loading … failed line, so the staged topology qcom/x1e80100/X1E80100-Dell-XPS-13-9345-tplg.bin loaded.
Sound itself is untested: no speaker or microphone test ran (the owner’s call, section “Next”).
| Boot | Kernel | Audio state | Evidence |
|---|---|---|---|
| -26 | #30 | 4 codecs enumerated, all deferred “Failed to get reset”; card deferred “WSA Playback: codec dai not found” | AP: GBOOK: deferred=sdw:4:0:0217:0204:00:0 wsa884x-codec: Failed to get reset (and :1, sdw:1 …); m3-aplay=… no soundcards found |
| -27 | #31 (RESET_GPIO=y) | reset.gpio.0 and .1 created, deferred “Could not get reset gpios”; codecs and card as on -26 | AP: GBOOK: deferred=reset.gpio.0 reset_gpio: Could not get reset gpios; m3-aplay=… no soundcards found |
| -28 | #32 (GPIO_SHARED_PROXY=y) | card 0 bound, playback device 1, capture device 3, UCM resolves | AP: m3-aplay=card 0: X1E80100DellXPS …, m3-arecord=… device 3, m3-alsaucm= 0: hw:0; no deferred= line |
Common to the three boots (netlog, kernel timestamps): PDR: Indication received from msm/adsp/audio_pd, state: 0x1fffffff at 1.05 to 1.09 s (the stock ADSP offers the audio protection domain); qcom-apm gprsvc:service:2:1: CMD timeout for [1001021] opcode at 6.12 s (APM_CMD_GET_SPF_STATE, audioreach.h:42: the first readiness poll from a DAI
probe times out, later ones answer, the card binds; a lead, not a blocker); wsa_macro …: Driver needs fixing: Unsorted reg_defaults and using zero-initialized flat cache (driver warnings, both macros); snd-x1e80100 sound: ASoC: Parent card not yet available, widget card binding deferred at 6.16 s on -28 (the card’s own deferral while the codecs probe).
What the boots proved about the mapping
- The SoundWire layout: the four WSA8845 enumerate as
sdw:1:0:0217:0204:00:0and:1(link 1 =swr0, unique ids 0 and 1) andsdw:4:0:0217:0204:00:0and:1(link 4 =swr3), as the stock codecswsa884x@02170220/1underwsa_swr_masterandwsa2_swr_mastersaid. The LPI pinswsa_swr_active(gpio10/11) andwsa2_swr_active(gpio15/16) carry the buses. - The shutdown pins TLMM 204 (bus 0’s pair) and 205 (bus 3’s pair) are the codecs’ resets: the codecs bound once the reset chain had its drivers, and the stock overlay’s pin groups are the same pins.
- Supplies:
vdd-1p8= L15B as in stock;vdd-io= L12B (every other x1e80100 board, not in stock): accepted by the probes, still unverified as the right rail. - DMICs and the mic rail: the VA macro bound with
dmic01_default/dmic23_defaultandvdd-micb-supply = <&vreg_dmic_3p3>(the stock overlay’sEN_PP3300_MICon TLMM 69); capture device 3 exists; no capture test ran.
The two blockers, both kernel options
At a804c57 the WSA884x driver asks the reset framework first (sound/soc/codecs/wsa884x.c:2022,
devm_reset_control_get_optional_shared); the reset core turns a reset-gpios property into an auxiliary reset-gpio
device (drivers/reset/core.c:1012-1105), one per distinct pin, and defers the consumer until that device’s driver binds.
That driver is CONFIG_RESET_GPIO, =m in the arm64 defconfig. With it built in (kernel #31) the reset-gpio devices
deferred themselves: TLMM 204 and 205 are each referenced by two codecs, and this kernel’s shared-GPIO support
(CONFIG_GPIO_SHARED=y, drivers/gpio/gpiolib-shared.c) flags such a pin GPIOD_FLAG_SHARED and routes every request
for it through a gpio-shared-proxy platform lookup (drivers/gpio/gpiolib.c:4805-4834), whose chip only the
CONFIG_GPIO_SHARED_PROXY driver registers (=m by default). Both are =y in kernel/mica-audio.config since kernel #32.
A distro kernel loads both as modules, which is why the Yoga Slim 7x never showed this.
Timing (boot -28, from the AP console and the journal)
| Point | Uptime | Evidence |
|---|---|---|
audio_pd up | 1.09 s | AP: PDR: Indication received from msm/adsp/audio_pd |
| first APM poll timeout | 6.12 s | AP: qcom-apm gprsvc:service:2:1: CMD timeout for [1001021] opcode |
| card’s widget binding deferred | 6.16 s | AP: snd-x1e80100 sound: ASoC: Parent card not yet available |
| card bound | before the first deferred read (empty) | AP: no GBOOK: deferred= line; the kernel logs no registration line |
m3-aplay | 52.2 s | AP: gbook-m3[2233]: GBOOK: m3-aplay=card 0: … |
m3-end | 55.7 s | AP: GBOOK: m3-end=uptime=55.69s |
The speaker test (2026-11-04, 11:51 PM EST): two of four units play, and the bus degrades
Owner’s OK given. Over ssh mica as root (the gbook user is not in audio: alsaucm and speaker-test see no card
without sudo -n; retro item): alsaucm -c X1E80100-Dell-XPS-13-9345 set _verb HiFi set _enadev Speaker (exit 0), then
speaker-test -D hw:0,1 -c 4 -t sine -l 1 (exit 0, 4 channels, 48 kHz; all four PA volumes at the cap of 6, digital volumes 81).
| Time (uptime of boot -28) | Played | Heard (owner) | Evidence |
|---|---|---|---|
| 506 s | 4-channel sine, one loop | two sounds, one louder, one lower; no left/right difference | boot28-speaker-test2.txt (scratch); AP: 6ab0000.soundwire: no slave alert found.spurious interrupt |
| 619 s | -t wav (spoken channel names), then two sine loops | “Front Right” and “Rear Right” (channels 1 and 3); four beeps | AP: 6ab0000.soundwire: qcom_swrm_irq_handler: SWR bus clsh detected |
| 685 to 708 s | each channel alone (-s 1..4), 8 s apart | one long loud beep, one long softer beep | boot28-speaker-test4.txt |
| 736 to 763 s | each channel alone at 250/500/1000/2000 Hz | no answer recorded | boot28-speaker-test5.txt |
| 957 and 974 s | 4-channel sine with bus 0 muted, then bus 3 muted (digital volumes by numid) | nothing, nothing | mute-test2.sh |
| 1018 s | 4-channel sine, every control restored | nothing | plain-test.sh |
What the device said meanwhile (root reads, files in the session scratchpad boot28-*.txt):
/sys/kernel/debug/gpio: TLMMgpio204andgpio205“out high” (both resets released; “out low” on boot -27 when the reset chain had no driver),gpio69“out high” (the mic rail).- DAPM during a tone (
/sys/kernel/debug/asoc/X1E80100-Dell-XPS-13-9345/*/dapm/*): both macros’WSA RX0/RX1paths On, and on all four codecs<name> IN: Onand<name> SPKR: On. The drivers believe all four play. /sys/bus/soundwire/devices/sdw:*/status:UNATTACHEDfor all four, before, during and after a tone (runtime_statusactiveduring it); the slaves’ debugfsregistersread a constant0x21(bus 0) or0for every register.- With
dyndbgondrivers/soundwire/qcom.c(1130 s):SWR new slave attached,Slave status not changed 1; then (1148 s, 1260 s)Slave status not changed 101,SWR unknown interrupt value: 2048(bit 11,SWRM_INTERRUPT_STATUS_AUTO_ENUM_FAILED,qcom.c:62, unhandled by the driver),SWR bus clsh detected,SWR read FIFO underflow fifo status 0x4000000f, on both masters. - The masters’ enumerator registers (
/sys/kernel/debug/soundwire/master-*/qualcomm-sdw/qualcomm-registers, decoded perqcom_swrm_enumerate,qcom.c:636-686): on each busSWRM_MCP_SLV_STATUS = 0x1(a slave attached at device number 0, never enumerated) and one enumerated slot, slot 1, id0x02170221: version 2, unique id 1, mfg 0x0217, part 0x0204. No slot carries unique id 0 on either bus.
Reading: on each bus the hardware auto-enumerator numbers only the unique-id-1 amplifier; the other amplifier stays at
device number 0 (AUTO_ENUM_FAILED, bus clashes), so the DT’s speaker@0,0 slaves never attach and get no port setup.
The audible pair are the two id-1 units: stock names bus 0’s wsa884x@02170221 “SpkrRight” and bus 3’s “Spkr2Right”
(the downstream node names are these very register values), so the owner heard the right-side woofer and tweeter: one
loud, one soft, no left/right difference. The left pair (stock @02170220, unique id 0) never enumerates. Why is open:
both amplifiers on a bus share one reset pin (as in stock), the same rails, the same bus; candidates are an id-0 amplifier
that answers the enumeration read late or not at all, two amplifiers strapped to the same unique id (a clash on the id
read), or a reset/timing order the stock driver handles and mainline’s does not. Sound then stops altogether after some
minutes: the re-enumeration after each bus clock-stop fails the same way, and reads of the id-1 slaves fail too
(FIFO underflow), inference from the debug lines at 1148 and 1260 s. sdw status UNATTACHED for the id-1 slaves while
they played is unexplained (the sysfs attribute may lag the hardware enumeration; unverified).
The debug boot (2026-11-05, 12:25 AM EST): all four enumerate at boot; the clock-stop exit loses them
Attempt 2026-11-05-1: the same TEST IMAGE with dyndbg="file drivers/soundwire/bus.c +p; file drivers/soundwire/qcom.c +p; file sound/soc/codecs/wsa884x.c +p" (image 22c46be8…, kernel #32), rootfs 6fea12f2… (the audio group, the m3-swrm
capture). Cold start, tally clean=1. Evidence: dumps/firstboot/2026-11-05-netlog.txt boot #1, 2026-11-05-ap.log,
dumps/firstboot/2026-11-05-ssh-*.txt (the mica-ssh.sh reads).
| Uptime | What | Evidence |
|---|---|---|
| 6.15 to 6.16 s | both buses enumerate both amplifiers: unique_id 0x1 as Slave 1, unique_id 0x0 as Slave 2, “signaling initialization completion” for all four | AP: soundwire sdw-master-4-0: SDW Slave Addr: 210217020400 … 200217020400; wsa884x-codec sdw:4:0:0217:0204:00:0: signaling initialization completion for Slave 2 (and bus 1) |
| 45.96 s | the first aplay -l wakes bus 0 from clock stop: Slave 1/2 state check1: UNATTACHED, two attach interrupts with Slave status not changed 0, then both re-enumerate; a burst of SWR read FIFO underflow follows | AP lines at 45.956 to 46.069 s |
| 47.15 s | bus 3 wakes the same way, with one SWR bus clsh detected, both re-enumerate | AP lines at 47.145 to 47.157 s |
| 48.25 s | m3-swrm=1-0: status=0x14 dev1=1 dev2=1 slot1=v2:uid1:0217:0204:00 slot2=v2:uid0:0217:0204:00; 4-0: (the same) | AP: GBOOK: m3-swrm= |
| 69.9 s | the first tone wakes both buses: UNATTACHED, SWR new slave attached three times, Slave status not changed 0, and no SDW Slave Addr line: neither bus re-enumerates; the enumerator reads status=0x1 dev0=attached no entry afterwards; owner heard nothing | 2026-11-05-ssh-audio-state.txt (first run); AP lines at 69.910 to 74.012 s |
| 145.9 s | the second tone: bus 0 re-enumerates both, bus 3 gets SWR unknown interrupt value: 2048 (AUTO_ENUM_FAILED), swrm_wait_for_wr_fifo_avail err write overflow, and its id-0 codec’s resume fails (ASoC error (-61) … pm_runtime_get); owner heard nothing | second audio-state run; AP lines at 145.86 to 153.46 s |
| 202.7 s | power/control=on on both masters (runtime PM forced on): both buses re-enumerate both amplifiers (status=0x14 on both, held through a second tone 27 s later); speaker-test -t wav: the owner heard “front left, front right, rear right, rear left”; the sine: a loud, a mid and a soft long beep | 2026-11-05-ssh-noclkstop.txt (both enumerator dumps decoded); AP lines at 202.767 to 202.790 s; Parity error detected twice on bus 3’s codecs |
Reading: the amplifiers and the mapping are right (all four enumerate at boot, with the unique ids the DT says), and
the two silent units of boot -28 were the losers of a race the Qualcomm master runs on every exit from clock stop: the
NEW_SLAVE_ATTACHED interrupts arrive before the hardware enumerator has filled its table, qcom_swrm_enumerate
finds nothing and completes, and the driver never retries (qcom.c:636-686; AUTO_ENUM_FAILED is unhandled, qcom.c:62).
Which bus wins is chance: both at 45.9 s, neither at 69.9 s, one at 145.9 s. With the masters kept clocked
(/sys/bus/platform/devices/6b10000.soundwire/power/control and 6ab0000.soundwire set to on) the slaves never
detach and all four play. The read FIFO underflow bursts on every wake (the codecs’ regcache_sync reads) and the two
Parity error detected lines remain open; they did not stop playback. The stock kernel’s log shows its driver meeting
the same class of errors with retries (swr_mstr_interrupt: SWR CMD error … flushing fifo, swrm_check_link_status;
dumps/firstboot/2026-11-05-stock-lastkmsg-swr.txt), and assigning devnum 1 to the id-1 units in the saved window; its VPHX EN Status line for 0220 is a register read that
needs the device number, so both amplifiers per bus enumerate on stock too, and on AUTO_ENUM_FAILED its driver re-arms the
hardware enumerator, which mainline’s does not (asoc-debug-tools.md, “The downstream driver”).
The udev-rule boot (2026-11-05, 1:01 AM EST): the rule’s own write is the first wake, and bus 1 lost it
Second boot of the same TEST IMAGE (22c46be8…, kernel #32; attempt 2026-11-05-1, netlog boot #2, clean), rootfs
59781d60… with /etc/udev/rules.d/90-gbook-soundwire.rules. Cold start, m3-end at 51.9 s. Evidence:
dumps/firstboot/2026-11-05-ap.log (the second boot), 2026-11-05-netlog.txt boot #2, 2026-11-05-ssh-audio-state.txt (the run at
12:59 AM EST).
| Uptime | What | Evidence |
|---|---|---|
| 6.15 to 6.16 s | all four amplifiers enumerate, as on the first boot | AP: SDW Slave Addr: 210217020400 … 200217020400 on sdw-master-1-0 and -4-0 |
| 35.93 s | the udev trigger’s power/control=on resumes both masters: a clock-stop exit on each. Bus 4 (6ab0000) re-enumerates both (Slave status not changed 14, then the two SDW Slave Addr lines by 36.00 s). Bus 1 (6b10000) gets SWR unknown interrupt value: 2048 (AUTO_ENUM_FAILED), Slave status not changed 101, three SWR new slave attached and no SDW Slave Addr line | AP lines at 35.926 to 36.049 s |
| about 7 min | audio-state.sh --tone: masters control=on status=active on both; decode master-1-0: status=0x1 dev0=attached no entry, master-4-0: status=0x14 dev1 dev2 | 2026-11-05-ssh-audio-state.txt |
Reading: the rule cannot protect the first wake, because its write is that wake (the masters autosuspend after probe, and
control=on resumes them through the same clock-stop exit). Bus 1 lost that one race and stays lost: the enumerator stalls as
on the first boot, with no later wake to re-roll it. The workaround is a coin toss per bus per boot, so it is not the
workaround; patch 0010 (which re-arms the stalled enumerator) is the fix under test next, on the same rootfs.
The patch boot, revision 1 (2026-11-05, 1:14 AM EST): the resume wait reads a stale status; a loss outside the resume path too
Attempt 2026-11-05-2: kernel #33 (7.3.0-gbook-2026.11.04-29-g50ac603-…, patch 0010 revision 1), image adf0c522…, the same
extras, rootfs 59781d60… (the udev rule). Cold start, m3-end at 50.4 s. Evidence: dumps/firstboot/2026-11-05-ap.log (third
boot), 2026-11-05-ssh-audio-state.txt (runs at 1:06, 1:07 and 1:11 AM EST), 2026-11-05-ssh-pm-auto.txt, 2026-11-05-ssh-swr-journal.txt.
| Uptime | What | Evidence |
|---|---|---|
| 6.16 s | all four enumerate | AP: the four SDW Slave Addr lines |
| 35.99 s | the rule’s control=on wake: both buses re-enumerate both (no stall this time) | AP lines at 35.986 to 36.000 s |
| about 1:06 AM | tone 1, masters on: both buses 0x14; the owner heard the three loudness levels | first audio-state run |
| 1:07:42 AM | owner OK: power/control=auto on both masters; both suspended within 4 s | 2026-11-05-ssh-pm-auto.txt |
| 146.11 s | tone 2’s wake. Bus 1: status 0, then 0x1 on the third attach interrupt, no SDW Slave Addr, no AUTO_ENUM_FAILED, no patch warn. Bus 4: both re-enumerated and initialised by 146.15 s, then at 146.37 s both UNATTACHED, status was 1 again; the dump ends status=0x1, slot1=v0:uid1:0000:0000:00 (a zeroed table entry) | journal lines 146.112 to 146.369 s; second audio-state run |
| 1:11 AM | tone 3: both buses still 0x1 dev0=attached no entry | third audio-state run |
Reading: revision 1’s wait in swrm_runtime_resume never fired. Right after the link comes back the status register still
reads the value from before the reset (both peripherals present), so the wait’s condition held at once; the real detach and
re-attach come later, through the interrupts. And a loss happened 240 ms after a good re-enumeration, outside the resume path
(bus 4 at 146.37 s), which no resume-side wait can see. Revision 2 (the next boot) checks 100 ms after every status change and
every resume whether a peripheral still sits at device 0, and re-arms the enumerator then; while the bus is short of its declared
peripherals it re-checks up to ten times. Note for the record: with the masters set to auto the buses did not recover by chance
across two further wakes.
The patch boot, revision 2 (2026-11-05, 1:25 AM EST): the check sees the stall, the downstream re-arm does not clear it
Attempt 2026-11-05-3: kernel #34 (patch 0010 revision 2), image f8d11625…, the same extras and rootfs. Cold start, m3-end
at 51.2 s. Evidence: dumps/firstboot/2026-11-05-ap.log (fourth boot), 2026-11-05-ssh-swr-journal-2.txt, 2026-11-05-ssh-pm-auto-2.txt,
2026-11-05-ssh-audio-state.txt (runs at 1:20 and 1:21 AM EST).
| Uptime | What | Evidence |
|---|---|---|
| 6.16 s | all four enumerate | AP: the four SDW Slave Addr lines |
| 36.95 to 37.10 s | the rule’s wake: both buses re-enumerate both; the new check reports enumeration check 0: slave status 0x14, enumerator status 0x0, 2 of 2 attached on each | AP lines at 36.953 to 37.100 s |
| about 1:20 AM | tone 1, masters on: both buses 0x14; the owner heard all the beeps | first audio-state run |
| 1:20:59 AM | owner OK: auto on both masters; both suspended within 4 s | 2026-11-05-ssh-pm-auto-2.txt |
| 116.52 s | tone 2’s wake. Bus 1: UNATTACHED, SWR bus clsh detected, status 0 then 0x1. Bus 4: Slave status not changed 1, then AUTO_ENUM_FAILED (the new handler: “re-arming the enumerator”). 100 ms later the check on each bus: enumeration stalled (slave status 0x1, enumerator status 0x3, 0 of 2 attached): re-arming the enumerator, enumerator status 0x3 not idle before re-arm; ten checks per bus, 100 ms apart, every one the same; the dump afterwards: both status=0x1 dev0=attached | journal lines 116.516 to 117.604 s; second audio-state run |
Reading: the detection is right and the downstream recipe is not enough here. SWRM_ENUMERATOR_STATUS sits at 0x3 (yesterday
0x6), and writing SWRM_ENUMERATOR_CFG 0 then 1 leaves it there. What has cleared this state every time so far is the boot
sequence: SWRM_COMP_SW_RESET, qcom_swrm_init (the CGCR reset, the frame, ping and FIFO configuration, the enumerator enabled,
the clock started), then the slaves attach and enumerate (8 of 8 at boot across four boots, and both buses at 35.9 to 37.1 s on
every rule wake). The clock-stop exit does only the CGCR reset and the clock restart (qcom.c:1751-1778 at a804c57), and that is
the path every wake has taken, because WSA884x sets simple_clk_stop_capable and not clk_stop_mode1 (wsa884x.c:2094); WSA881x
sets clk_stop_mode1 (wsa881x.c:1134) and its controllers take the full-init path on every resume. Revision 3 of 0010 escalates a
re-arm that leaves the enumerator busy to the reset-and-init sequence; patch 0011 sets clk_stop_mode1 for WSA884x so every resume
takes the full-init path in the first place. Both for the next boot.
The patch boot, revision 3 and patch 0011 (2026-11-05, 1:34 AM EST): three wakes, all four amplifiers back each time
Attempt 2026-11-05-4: kernel #35 (7.3.0-gbook-2026.11.04-35-g7c6a1aa-…, patch 0010 revision 3 and patch 0011), image 62a2e345…,
the same extras and rootfs (59781d60…, the udev rule). Cold start, m3-end at 50.4 s. Evidence: dumps/firstboot/2026-11-05-ap.log
(fifth boot), 2026-11-05-ssh-pm-auto-3.txt, 2026-11-05-ssh-audio-state.txt (runs at 1:31, 1:32 and 1:33 AM EST).
| Uptime | What | Evidence |
|---|---|---|
| 6.15 s | all four enumerate; enumeration check 0: … 2 of 2 attached on both buses at 6.26 s | AP lines at 6.147 to 6.257 s |
| 36.21 s | the rule’s wake, now through the full-init resume path (0011): both buses 2 of 2 | AP lines at 36.211 s |
| about 1:31 AM | tone 1, masters on: both buses 0x14; the owner heard all the beeps | first audio-state run |
| 1:32:43 AM | owner OK: auto on both masters; both suspended within 4 s | 2026-11-05-ssh-pm-auto-3.txt |
| 173.58 s | tone 2’s wake: both buses UNATTACHED then SDW Slave Addr for both amplifiers within 300 ms (bus 1 by 173.60 s, bus 4 by 173.86 s); 2 of 2 attached on both; no stall, no AUTO_ENUM_FAILED, no escalation; the owner heard all the beeps | AP lines at 173.584 to 173.973 s; second audio-state run |
| 212.88 s | tone 3’s wake, a minute later: the same, 2 of 2 on both | AP lines at 212.877 to 213.137 s; third audio-state run |
Reading: with clk_stop_mode1 set on WSA884x (0011) every resume runs SWRM_COMP_SW_RESET, qcom_swrm_init and the enumeration
wait, the sequence that has enumerated at every boot, and three wakes in a row came back whole where boots -2 and -3 lost a bus
on the first. Revision 3’s escalation (reset and init from the check) did not have to fire; its detection lines (2 of 2 attached)
are the evidence that each wake completed. Open: whether 0011 alone is the fix (0010’s escalation is unexercised), the 10-minute
idle case from the ticket’s bar, the Parity error detected lines, and the udev rule, which can now go.
The rule-free boot (2026-11-05, 2:05 AM EST): the full bar on kernel #35, no udev rule
Second boot of attempt 2026-11-05-4’s image (kernel #35, patches 0011 and 0010 revision 3), rootfs 6fea12f2… (no udev rule: the masters
read control=auto status=suspended before every tone). Cold start, m3-end at 51.8 s. Evidence: dumps/firstboot/2026-11-05-ap.log
(sixth boot), 2026-11-05-netlog.txt boot #6, 2026-11-05-ssh-audio-state.txt (runs at 1:53, 1:54 and 2:04 AM EST),
2026-11-05-ssh-speaker-names-2.txt.
| Uptime | What | Evidence |
|---|---|---|
| 6.27 s | all four enumerate; 2 of 2 attached on both buses | AP lines at 6.265 and 6.273 s |
| 46.5 and 47.6 s | the M3 script’s own reads wake the masters: 2 of 2 each | AP lines at 46.457 and 47.641 s |
| 64.0 s | tone 1 (1:53 AM): both buses 0x14; the owner heard the beeps | AP lines at 63.993 to 64.257 s; first audio-state run |
| 129.4 s | tone 2 a minute later: both 0x14; the owner counted eight beeps (four channels, two loops) | AP lines at 129.427 to 129.685 s; second run |
| 761.8 s | tone 3 after 10 minutes idle (2:04:39 AM): both 0x14, 2 of 2 | AP lines at 761.847 to 762.121 s; third run |
| about 2:05 AM | speaker-test -D hw:0,1 -c 4 -t wav -l 1: Front Left, Front Right, Rear Right, Rear Left (first try -16 busy: the tone was still playing) | 2026-11-05-ssh-speaker-names-2.txt |
Reading: every wake of this boot (five, counting the script’s reads) brought both buses back whole; no stall, no AUTO_ENUM_FAILED,
the escalation never fired. The owner’s hearing reports for tone 3 and the names are in ticket 16.
The capture test (2026-11-05, 9:26 AM EST): the four DMICs record, and the owner heard the playback
Boot 7 of the day (netlog #7, attempt 2026-11-05-4’s image, kernel #35, rootfs 6fea12f2…; cold start, clean, SCMI 0.1 ms), the
TEST IMAGE still on the stick (dts/diag/sound.dtsi extra; the same node sits in the board DTS since commit 9d120a5). Over ssh:
alsaucm -c X1E80100-Dell-XPS-13-9345 set _verb HiFi list _devices lists 0: Speaker and 1: Mic (“Internal microphones”); one
invocation enabled both (set _enadev Speaker set _enadev Mic), then arecord -D hw:0,3 -c 2 -f S16_LE -r 48000 -d 10 /tmp/mic.wav
while the owner spoke, then aplay -D plughw:0,1 /tmp/mic.wav (exit 0). The owner heard their own voice from the speakers
(report at 9:26 AM EST). The file, measured on the build host (dumps/firstboot/2026-11-05-mic.wav, gitignored): 480000 frames, RMS about 900 on
the left channel and 1200 on the right, varying second by second (1506 and 2776 in the first second, 444 and 408 in the last), peaks
at full scale once per channel (inferred: the start click). The journal has no VA macro, DMIC or LPASS line for the capture.
So the mic rail (EN_PP3300_MIC, TLMM 69, as vdd-micb-supply) and the DMIC clock (qcom,dmic-sample-rate = <4800000>, divider 16)
work as described; dts/README.md, “Unverified”, records which values stay the Yoga’s. Evidence:
dumps/firstboot/2026-11-05-ssh-ucm-devices.txt, -ssh-capture.txt, -ssh-playback.txt, -ssh-va-journal.txt.
The 0011-alone boot (2026-11-05, 12:32 PM EST): patch 0011 carries the fix
Attempt 2026-11-05-6 (kernel #36, patches 0001 to 0009 and 0011, 0010 set aside for this build only and restored in the repo; the
release string carries + for the set-aside file; TEST IMAGE bf48ab37…, SoundWire dyndbg; rootfs 6fea12f2…; cold, clean).
Tone 1 at 12:29 PM EST (first wake), tone 2 at 12:31 PM EST after both masters read suspended, the names right after: every wake
re-enumerated both amplifiers on both buses (master-1-0 and master-4-0 status=0x14 dev1=attached dev2=attached), the journal
shows only the read FIFO underflow bursts at each wake, no stall, no AUTO_ENUM_FAILED. The owner heard tone 1, tone 2 and the
four names twice (reports at 12:30 and 12:32 PM EST). So the full-init resume path that 0011 selects (clk_stop_mode1 on WSA884x) is the fix;
0010’s stall check and escalation never had to act on kernel #35 and are absent here with the same result. Owner decision (12:38 PM EST): 0010 stays until the M5 patch
review, then it is dropped (one patch fewer to defend). The same boot showed /init’s new
GBOOK: lock-ro=none: only the stick (sda) (task #36). Evidence: dumps/firstboot/2026-11-05-ssh-audio-state.txt (the last three
runs), 2026-11-05-ssh-swr-journal.txt, netlog boot #11.
Next
- Workaround in the rootfs: not a workaround (“The udev-rule boot”); to be removed from
rootfs/customize.shnow that the patches pass. - The driver fix passes the ticket’s bar (“The rule-free boot”, 2:05 AM EST): tones a minute apart, a tone after 10 minutes idle, the four names, all on the rootfs without the udev rule. Both patches stay (ticket 16). The 0011-alone boot (“The 0011-alone boot”, 2026-11-05) shows 0011 carries the fix; 0010’s fate is the owner’s call.
- The reads planned on 2026-11-04 for the left amplifiers ran on 2026-11-05-1 (“The debug boot”); the stock log read is now
scripts/recon.sh stock-kmsg '<regex>'. - Tools for those reads: asoc-debug-tools.md (research pass, 2026-11-04).
- The ssh user joins
audio(rootfs/customize.shgroup loop), so the tests run withoutsudo -n. - The speaker test as run tonight is the regression check:
speaker-test -D hw:0,1 -c 4 -t wav -l 1right after boot, all four names audible. The PA volumes stay at the driver’s cap of 6 (x1e80100.c:42-51). - Capture test: passed (“The capture test”, 2026-11-05). The sound node is in the board DTS (commit
9d120a5). Next: a base image, three clean cold boots, the release. - The APM first-poll timeout at 6.12 s: read
q6apm.cfor the poll’s caller and timeout; a lead for boot time, not for function.