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:
- 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