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

[Takashi Iwai]

On Fri, 24 May 2019 15:26:54 +0200,
Pierre-Louis Bossart wrote:
> 
> 
> 
> 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.

Yes, it sounds reasonable.


thanks,

Takashi