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