Re: [Bug 214995] New: Sof audio didn't recognize Intel Smart Sound (SST) speakers, microphone and headphone jack

[Bjorn Helgaas <helgaas@kernel.org>]

On Fri, Nov 12, 2021 at 09:11:45AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=214995
> 
>             Bug ID: 214995
>            Summary: Sof audio didn't recognize Intel Smart Sound (SST)
>                     speakers, microphone and headphone jack
>            Product: Drivers
>            Version: 2.5
>     Kernel Version: 5.11.0-40-generic
>           Hardware: Intel
>                 OS: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: high
>           Priority: P1
>          Component: PCI
>           Assignee: drivers_pci@kernel-bugs.osdl.org
>           Reporter: nicolarevelant44@gmail.com
>         Regression: No
> 
> Created attachment 299549
>   --> https://bugzilla.kernel.org/attachment.cgi?id=299549&action=edit
> The output of dmesg and lspci -v
> 
> I have a Huawei Matebook D15 notebook with Intel Smart Sound Technology as
> sound card. SST includes speakers, microphone and headphone jack so none of the
> 3 work. Bluetooth and USB headphones work. I have already tried to change
> "options snd_intel_dspcfg dsp_driver" and reload alsa (alsa reload) for each
> value but nothing (only small changes in dmesg).
> The first lines of dmesg_dump.txt are errors because of the 'alsa reload'
> command. The log is verbose because I add some options from this web page:
> https://thesofproject.github.io/latest/getting_started/intel_debug/suggestions.html
> 
> My sound card is listed in PCI so the last lines of dmesg_dump.txt are the
> output of the 'lspci -v' command
> 
> aplay -l shows only 3 HDMI outputs with sof-hda-dsp

Hi Nicola,

Thanks very much for the report and sorry for the problem.

It's possible there's a power management issue, e.g., reads to the
00:1f.3 device are timing out because the device is in D3cold, but I
can't tell from the part of the dmesg log you attached.  In that case,
reads will generally return ~0 (0xffffffff), but it looks like some
reads *do* return valid data, e.g.,

  sof-audio-pci 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100
  sof-audio-pci 0000:00:1f.3: found ML capability at 0xc00

I don't see an obvious PCI core connection here, so I cc'd the SOF
maintainers in case they have any insight.

  - It looks like you're running v5.11.0.  Can you reproduce the same
    problem on a current kernel, e.g., v5.15?  It's possible the
    problem has been fixed since v5.11.

  - Did this ever work?  In other words, is this a regression?  If so,
    what's the newest kernel you know of that *did* work?  In the
    worst case, we could bisect to identify a change that broke it.

  - It might be useful if you could attach the complete dmesg log and
    output of "sudo lspci -vv" to the bugzilla.

Bjorn