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