Re: [PATCH v3 0/2] ASoC: fix audio on the Microsoft Surface Pro 11 (Intel)

[Sergey Lebedev <lsa.uz@pm.me>]

Please do not apply 1/2. I cannot reproduce the condition it fixes, and I
would rather say so myself than have it found in review.

The patch rests on one claim: that this part never sets
FUNCTION_NEEDS_INITIALIZATION, so rt1320_io_init() never runs the vendor
preset and the amplifier is never programmed. Every func_status line I
recorded in July reads 0x41 - NEWLY_ATTACHED | FUNCTION_HAS_BEEN_RESET,
without BIT(5).

Re-tested tonight on the same machine, with the stock rt1320 driver and my
patch not loaded:

  rt1320-sdca sdw:0:0:025d:1320:01: rt1320_io_init amp func_status=0x61
  rt1320-sdca sdw:0:0:025d:1320:01: rt1320_vc_preset, RT1320_KR0_INT_READY=0x0
  rt1320-sdca sdw:0:0:025d:1320:01: rt1320_vc_preset, RT1320_KR0_INT_READY=0x1f

0x61 is 0x41 | BIT(5). The bit is set, the stock driver runs the preset, and
the patch is a no-op. Same reading in three configurations - with the ghost
_ADR removed, with a machine-entry approach that leaves it enumerated, and
fully stock - and on a genuine cold boot, not a reboot: the previous boot
ended in systemd-poweroff and an RTC alarm brought the machine back from S5.

The speakers work without the patch, and I checked that by measurement rather
than by reading logs, because silence with every layer reporting success is
the exact failure mode here. Playing a 1 kHz tone and recording the internal
microphone, the 1 kHz bin rises 185x over ambient with the patch absent, 610x
with it present. Both are unambiguously audible; the difference is room noise.

What I ruled out:

  - the gate is unchanged. if ((amp_func_status & FUNCTION_NEEDS_INITIALIZATION))
    is identical in v7.0 and v7.1-rc7, the tree this series targets
  - Ubuntu changed nothing relevant between 7.0.0-28 and 7.0.0-30: no rt1320,
    sdca, soundwire or sdw entry in the changelog
  - firmware predates the July readings. firmware-sof-signed went to 2025.12.2
    on 2026-07-27 and the Surface firmware bundle was applied 2026-07-28
  - the ghost is not involved: fully stock, it never reaches rt1320_io_init()
    at all, and the real device still reports 0x61

So I have no explanation for the change, and I am not going to invent one. If
someone knows how an SDCA part stops asserting that status bit between one
month and the next, I would like to hear it - that is worth more to the
subsystem than the patch was. I still have the hardware and will test whatever
is useful.

2/2 is unaffected and I would ask that it still be considered. I re-verified it
the same night by running fully stock:

  sysfs: cannot create duplicate filename '.../sof_sdw/SDW0-Capture-SmartMic'
  kobject_add_internal failed for SDW0-Capture-SmartMic with -EEXIST
  sof_sdw sof_sdw: probe with driver sof_sdw failed with error -12

aplay -l reports zero cards. Without the quirk this machine has no audio device
at all, so that patch is not an optimisation.

One more result from the same night, since it bears on the approach. I compared
this series against the downstream machine-entry patch that Surface Pro 11 users
run today, on one machine and one kernel, swapping only the audio modules. Both
end up with the same configuration - same three function topologies, 4 playback
+ 1 capture, rt1320-1, working microphone. The difference is what each costs:
the machine entry does not match at all unless class_id is added to
SDW_CODEC_ADR_MASK and to the peripheral comparison in soc-acpi.c, because
generic matching sees two peripherals for the one address it declares. That is
shared code for every SoundWire machine. Removing the ghost at enumeration needs
no such change.

Sorry for the noise on 1/2.

Thanks,
Sergey