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=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. > > 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
