[alsa-devel] [RFC PATCH 0/6] ALSA/HDA: abort probe when DMICs are detected

Pierre-Louis Bossart pierre-louis.bossart at linux.intel.com
Tue Jun 18 08:51:27 CEST 2019


>>>>> I am not sure if it's a good idea to enable this by default, the
>>>>> experience of the first round showed it's risky to make assumptions on
>>>>> what BIOS vendors implemented.
>>>>
>>>> Can you clarify what you mean here, are you saying you don't want to
>>>> enable this new DMIC hardware support by default?
>>>
>>> No. What I am saying is that
>>> a) the legacy HDaudio driver does not support DMICs
>>> b) the decision to abort the HDaudio legacy driver probe should not 
>>> be the default, since it depends on BIOS information that may be 
>>> wrong and on which I have *zero* control.
>>>
>>> There are 4 cases really:
>>>
>>> 1. DMICs attached to PCH and BIOS/NHLT reports DMICS -> abort HDaudio 
>>> legacy probe
>>> 2. No DMICs attached to PCH and BIOS/NHLT does not report DMICs -> 
>>> continue probe and use HDAudio legacy.
>>> 3. DMICs attached to PCH and BIOS/NHLT does not report DMICs -> 
>>> broken config, we will need an option to abort the probe by force and 
>>> ignore the BIOS if you care about audio capture.
>>> 4. no DMICs attached to PCH and BIOS/NHLT reports DMICs -> broken 
>>> config, we need an option to ignore the BIOS and continue the probe.
>>
>> Got it,  we will do a test on a couple of machines, let us see if we 
>> can meet 3 and 4 in reality.
> 
> I backported these 6 patches to our 5.0 kernel with the sof driver in 
> it, and tested on 3 machines which have dmic connected to PCH (audio 
> controller pciid 0x9dc8), without these 6 patches, I need to blacklist 
> snd_hda_intel.ko and snd_soc_skl.ko to make the sof driver work, after 
> backporting these 6 patches, I don't need to blacklist snd_hda_intel.ko, 
> but still need to blacklist snd_soc_skl.ko, otherwise the sof driver 
> doesn't work.
> 

Thanks for testing. I've done additional updates on my side and I am 
reasonably confident we can make this SOF/legacy autodetect work.

> And I also tested these 6 patches on 3 machines without dmic, I don't 
> need to blacklist anything, the audio works well via legacy hdaudio.
> 
> So for coexistence  of soc_skl and soc_sof drivers, do we have any plan?

HDaudio is not well supported by the SKL driver. We introduced this 
support in v4.19, but there are quite a few issues on specific platforms 
that are not well handled (questionable probe which lead to breaking 
audio on Linus' laptop, interrupt issues fixed with SOF and legacy, 
etc). Since SOF is well supported on those platforms, I am honestly 
leaning to de-feature HDAudio support from the SKL driver (as in make 
the HDaudio codec Kconfig option not recommended) and apply the same 
trick as for the legacy to abort the probe if there is no I2S codec and 
DMICs are detected. It would have no effect on any users and would help 
distros like Ubuntu avoid the need for blacklists. We can also apply 
DMI-based quirks for Chrome, e.g. for now all platforms prior to GLK 
should use SKL and more recent ones SOF.


More information about the Alsa-devel mailing list