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

Pierre-Louis Bossart pierre-louis.bossart at linux.intel.com
Mon Nov 15 18:49:22 CET 2021



On 11/12/21 4:24 PM, Bjorn Helgaas wrote:
> On Fri, Nov 12, 2021 at 09:11:45AM +0000, bugzilla-daemon at 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 at kernel-bugs.osdl.org
>>           Reporter: nicolarevelant44 at 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.

That seems like a known issue already tracked at
https://github.com/thesofproject/linux/issues/3248

There's a set of devices based on the ES8316/36 I2S audio codec which
needs dedicated quirks. In the existing reports the Huawei Matebook D15
is listed as using that codec.

The latest experimental code we have is here:
https://github.com/thesofproject/linux/pull/3107/commits

If confirmed, can we track this on GitHub so that all results for this
sort of devices are collected in one place? Thanks!




More information about the Sound-open-firmware mailing list