[alsa-devel] "ALSA: HD-Audio: SKL+: abort probe if DSP is present and Skylake driver selected" breaks sound, suspend on Apollo Lake

[Pierre-Louis Bossart]

On 12/30/18 8:39 AM, Hans de Goede wrote:
> Hi,
> 
> On 26-12-18 18:53, Pierre-Louis Bossart wrote:
>>
>> On 12/25/18 7:10 AM, Hans de Goede wrote:
>>> Hi Pierre-Louis,
>>>
>>> Since I recently have been doing a bunch of i915 work I'm currently
>>> running drm-tip. This brought in this commit from next:
>>>
>>> https://cgit.freedesktop.org/drm-tip/commit/?id=c337104b1a16becc486fdc95d544c835b17021db 
>>>
>>>
>>> This causes the hda driver to not bind to the audio on my Apollo Lake
>>> based laptop, and the asoc driver errors out with:
>>>
>>> [   19.176417] skl_hda_dsp_generic skl_hda_dsp_generic: Unsupported 
>>> HDAudio/iDisp configuration found
>>> [   19.176428] skl_hda_dsp_generic: probe of skl_hda_dsp_generic 
>>> failed with error -22
>>>
>>> After which I get no sound and worse, the machine hangs on suspend.
>>> It seems to never reach its fully suspended state (the power-led
>>> never starts to fade on/off as it normally does when suspended).
>>>
>>> I've been looking through the Kconfig option and it seems that
>>> currently selecting SND_SOC_INTEL_APL makes little sense since there
>>> are 0 machine drivers for this setup ?
>>>
>>> I guess I can fix this by unselecting SND_SOC_INTEL_SKYLAKE and
>>> then during the manual platform selection not selecting
>>> SND_SOC_INTEL_APL, but IMHO we need to put something in place
>>> where the hda driver actually checks if there is a machine driver
>>> and if there isn't one then we should keep using the hda driver
>>> on the machine in question.
>>
>> Interesting, thanks for the bug report.
>>
>> There are three problems here:
>>
>> 0. How did this work before? if you didn't have a blacklist, you had 
>> two drivers registering for the same PCI ID, so were relying on an 
>> implicit behavior.
> 
> Yes I believe that before this used to work because the snd-hda-intel
> module simply got loaded / bound first.
> 
> ls -l /sys/bus/pci/devices/0000\:00\:0e.0/driver
> 
> Shows snd_hda_intel is bound with kernel 4.18.13-300.fc29.x86_64

Bummer. It looks like I made a wrong assumption here. I assumed only 
Chromebooks enabled the ASoC-based driver with the SND_SOC_SKYLAKE 
option and no other distribution did since that driver would never work 
(DSP not enabled and/or missing userspace files), or that distributions 
used blacklists to avoid conflicts. If they enabled SKYLAKE and didn't 
add blacklists then things just happened to work by accident and not by 
design.

If we want to be backwards compatible with this implicit behavior, I 
wonder if we should change the default to force the use of the legacy 
driver unless the distribution sets the 'pci_binding' module option 
asking for the automatic detection.

in other words pci_binding=0 -> force legacy (implicit default), 
pci_binding=1 -> force ASoC, pci_binding=2 -> auto-detection.

diff --git a/include/sound/hdaudio.h b/include/sound/hdaudio.h
index b4fa1c775251..e5ef7e8a08aa 100644
--- a/include/sound/hdaudio.h
+++ b/include/sound/hdaudio.h
@@ -99,9 +99,9 @@ enum {
  };

  enum {
-       SND_SKL_PCI_BIND_AUTO,  /* automatic selection based on pci class */
         SND_SKL_PCI_BIND_LEGACY,/* bind only with legacy driver */
-       SND_SKL_PCI_BIND_ASOC   /* bind only with ASoC driver */
+       SND_SKL_PCI_BIND_ASOC,  /* bind only with ASoC driver */
+       SND_SKL_PCI_BIND_AUTO   /* automatic selection based on pci class */
  };

  /* direction */

> 
>> 1. why does the HDaudio support in the SKL driver fail?  I am not sure 
>> what's going on here. If your device has the DSP enabled, then the 
>> HDaudio SKL part should just work. It works on my APL NUC.
> 
> Well my laptop does not have a HDMI port, only a Type-C port (with DP 
> support),
> note that the i915 driver does seem to think it has HDMI ports, but maybe
> it configures these as not audio capable ?   :
> 
> [root at localhost ~]# ls /sys/class/drm/
> card0       card0-HDMI-A-1  card0-eDP-1  version
> card0-DP-1  card0-HDMI-A-2  renderD128
> 
>> Would you mind sharing the .config and full dmesg log with -DDEBUG 
>> enabled for sound/soc/codecs and sound/soc/intel? The "unsupported 
>> configuration found" typically means the i915 driver isn't working or 
>> creating the iDISP codec since we assume HDMI is always present.
> 
> Both are attached.

I see no information from hdac_hdmi.c. Maybe we should look at 
/sys/kernel/debug/asoc/* to see what dais are created.


> 
>> 2. how do we 'backtrack' in case the SKL driver fails? That one I 
>> don't have a good solution for. You should be well past the firmware 
>> initialization steps and at this point it's too late to return -ENODEV 
>> to let the legacy audio take over.
> 
> Good question.
> 
> 
> On 30-12-18 09:50, Takashi Iwai wrote:
>  > Maybe this is the the same problem Linus (Cc'ed) hit recently, too?
>  >
>  > A regression with Dell XPS is that, because the device has PCI class
>  > 0x4380 (which implies that DSP is available), now we skip the binding
>  > with the legacy driver and let go with ASoC.
>  >
>  > Meanwhile, ASoC driver requires either the specific machine driver for
>  > the specific configuration or the binding with the legacy codec
>  > drivers.  Dell XPS is the latter, and this failed due to the lack of
>  > iDisplay connection.
>  >
>  > Hans, is yours also the same case?  Please check whether which driver
>  > was used in the earlier kernel.  If it's snd-hda-intel in the past,
>  > the above is the likely scenario.
> 
> Yes my laptop is using the snd-hda-intel driver before these commits.
> 
> As for the issue Linus is seeing, if this is a newer model XPS it
> likely also does not actually have a (physical) HDMI connector.

I vaguely recall that on the KabyLake version of the Dell XPS13 the DSP 
can be disabled or enabled through the BIOS menu. I am wondering if 
Linus' laptop had this option enabled and fails due to a missing 
topology file, or if the errors reported are linked to HDMI/DP as for Hans.