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

Pierre-Louis Bossart pierre-louis.bossart at linux.intel.com
Fri May 24 15:26:54 CEST 2019



On 5/24/19 2:58 AM, Takashi Iwai wrote:
> On Fri, 24 May 2019 01:39:45 +0200,
> Pierre-Louis Bossart wrote:
>>
>> This is the second take on same problem of detecting when the HDaudio
>> legacy driver can be used and when the SST or SOF drivers are
>> required.
>>
>> The previous attempt based on a the PCI Class information was a
>> resounding failure and broke audio on Linus' laptop, so we need
>> additional information to avoid enabling a DSP-based driver without a
>> good reason to do so.
>>
>> This patchset suggests the use of the NHLT information which *in
>> theory* exposes DMIC endpoints. The legacy HDaudio driver cannot
>> handle DMICs and will not provide any capture capabilities. Since it's
>> typically the first one to probe due to the Makefile order, aborting
>> the probe will let the PCI subsystem look for the next driver which
>> hopefully will support this capability.
>>
>> I tested this patch on 5 devices (SKL, KBL, APL, GLK, WHL), three
>> without DMICs and two with, and the detection seems to work as
>> planned. I would appreciate it if HDaudio integrators and folks at
>> Google/Canonical/Endless can give this a try. As usual I expect that
>> we will have to use quirks and work-arounds, but it'd be a better idea
>> than a build-time mutual exclusion. We could also make this optional
>> (Kconfig and/or module parameters) if people prefer to muck with
>> blacklists.
>>
>> Feedback and comments welcome!
> 
> The general idea and suggested implementation look almost good to me.
> Of course we have to provide a way to override the default behavior in
> case of buggy BIOS (I bet a drink for the existence of such :)

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.
I'd rather make this an opt-in solution for distros that have to deal 
with this conflict and don't want to use blacklists, and provide both a 
Kconfig and kernel parameter to either statically or dynamically enable 
this capability. Also this is really needed mostly with WHL+ platforms 
where a lot of vendors use DMICs, for previous generations there are 
only Chromebooks and a single-digit number of KBL devices.


More information about the Alsa-devel mailing list