[alsa-devel] "ALSA: HD-Audio: SKL+: abort probe if DSP is present and Skylake driver selected" breaks sound, suspend on Apollo Lake
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=c337104b1a16becc486fdc95d544... 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. Regards, Hans p.s. Merry Christmas!
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=c337104b1a16becc486fdc95d544...
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. 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. 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. 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.
Regards,
Hans
p.s.
Merry Christmas!
On Wed, 26 Dec 2018 18:53:03 +0100, 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=c337104b1a16becc486fdc95d544...
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.
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. 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.
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.
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. thanks, Takashi
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=c337104b1a16becc486fdc95d544...
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
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@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.
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. Regards, Hans
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=c337104b1a16becc486fdc95d544...
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@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.
Hi, On 12/30/18 11:10 PM, Pierre-Louis Bossart wrote:
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=c337104b1a16becc486fdc95d544...
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.
Yes that seems to be the case. I see that the changes causing the problem will be reverted for now, but still if this is an option which dsitros should not be enabled then maybe the Kconfig help text need to be updated to reflect this ? If you can write something about why this should not be enabled by distros then I can get the kernel-config for Fedora updated. Regards, Hans
participants (3)
-
Hans de Goede -
Pierre-Louis Bossart -
Takashi Iwai