[alsa-devel] "ALSA: HD-Audio: SKL+: abort probe if DSP is present and Skylake driver selected" breaks sound, suspend on Apollo Lake

[Hans de Goede]

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