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

[Takashi Iwai]

On Tue, 18 Jun 2019 08:51:27 +0200,
Pierre-Louis Bossart wrote:
> 
> 
> >>>>> 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.

As far as the functionality is kept from use POV, it should be fine.
And yes, blacklisting is no primary option.

I guess we can start tweaking Kconfig to disable HD-audio on SKL SSL
while keeping the code intact.


thanks,

Takashi