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