From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DFB38C432C2 for ; Tue, 24 Sep 2019 07:32:04 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DEB372053B for ; Tue, 24 Sep 2019 07:32:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="mL1q8fek" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DEB372053B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id C6D7116AB; Tue, 24 Sep 2019 09:31:11 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz C6D7116AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1569310321; bh=syLjsZ5R5W4zd7al51Z5krBokw9UWQOfCyRRsVRL5xs=; h=Date:From:To:In-Reply-To:References:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=mL1q8fekjnYssUYaMdB9w6PGpeU6uK+5TYQtW8RESTm/dV1TmnOIcUmgwCeh5zrU3 htnwHrQB5Oh8zChlUK9bPhkR4mrk6WqboaghAdCmNcvJ1L8d/62f54lqWkh/CQTh8N AIz/jX48EgK9dt1fLpcb6uWHjaEy4EX9EsKlApYk= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 3AE9EF803F4; Tue, 24 Sep 2019 09:31:11 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 32890F8045F; Tue, 24 Sep 2019 09:31:09 +0200 (CEST) Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 05F52F800B4 for ; Tue, 24 Sep 2019 09:31:05 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 05F52F800B4 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 3CBB2B6E0; Tue, 24 Sep 2019 07:31:03 +0000 (UTC) Date: Tue, 24 Sep 2019 09:31:00 +0200 Message-ID: From: Takashi Iwai To: Jaroslav Kysela In-Reply-To: <19cfb65e-e539-2225-82a5-813ab9be9f2b@perex.cz> References: <20190923165739.3975-1-perex@perex.cz> <19cfb65e-e539-2225-82a5-813ab9be9f2b@perex.cz> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Cc: ALSA development , Pierre-Louis Bossart Subject: Re: [alsa-devel] [PATCH] ASoC: Skylake SST driver - blacklist the PCI device IDs for the auto probe X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Tue, 24 Sep 2019 08:46:44 +0200, Jaroslav Kysela wrote: > > Dne 24. 09. 19 v 1:34 Pierre-Louis Bossart napsal(a): > > On 9/23/19 4:21 PM, Takashi Iwai wrote: > >> On Mon, 23 Sep 2019 22:35:14 +0200, > >> Jaroslav Kysela wrote: > >>> > >>> Dne 23. 09. 19 v 20:24 Pierre-Louis Bossart napsal(a): > >>>> On 9/23/19 11:57 AM, Jaroslav Kysela wrote: > >>>>> There are basically three drivers for the PCI devices for > >>>>> the recent Intel hardware with the build-in DSPs. The legacy HDA > >>>>> driver has dmic_detect module option for the auto detection > >>>>> of the platforms with the digital microphone. Because the SOF > >>>>> driver is preferred, just skip PCI probe in the Skylake SST > >>>>> driver when the PCI device ID clashes by default. The user > >>>>> can override the auto behaviour with the pci_binding > >>>>> module parameter. > >>>> > >>>> Thanks Jaroslav for re-opening this mutual-exclusion issue. > >>>> > >>>> I think we want to deal with this in two alternate ways > >>>> 1. static built-time exclusion based on Kconfigs > >>> > >>> Unfortunately, that's really an issue for the universal distros. > >> > >> Right. The Kconfig of Intel audio is already too messy even for now. > >> We don't want more complexity just for covering some very corner > >> case. > >> > >> Practically seen, if SOF Kconfig is enabled, we may assume that SOF is > >> preferred in general. I don't think of any big need of yet another > >> static configuration. > >> > >>>> 2. probe-time exclusion based on quirks (CPU ID + DMI) > >>>> > >>>> For example with a SKL/KBL/APL chromebook w/ DMIC we'd want to use the > >>>> SST driver and for GLK+ we want to use SOF. For any device with > >>>> HDAudio+DMIC we'd want SOF, same for any device with SoundWire when it's > >>>> fully supported. > >>>> > >>>> I can't recall if I shared the patches I worked on a couple of months > >>>> ago, but they are still at https://github.com/thesofproject/linux/pull/927 > >>> > >>> Thanks for pointing me to this. It does not address the legacy HDA, but it's a > >>> step forward. > >> > >> The legacy HD-audio stuff is resolved with the recent DMIC detection > >> on 5.4, I suppose? > > Unfortunately not completely. The Broxton and Coffelake PCI IDs are also > shared by the SST / Legacy HDA drivers, so the universal kernel will be > confused (at least snd_hda_intel will be loaded as first). Yes, that's a missing piece. OTOH, the situation wrt these platforms hasn't been changed, so it's no regression, at least. > >>>> the first part essentially does the same thing as this patch, the second > >>>> relies on quirks. I've been busy with other things but indeed it's high > >>>> time we closed this for distributions. > >>> > >>> Yes, and I have to say, it's too late for the hardware vendors right now. I > >>> will probably apply my patch to our distribution (I don't care too much about > >>> chromebooks - the user can change the module/driver behaviour manually) until > >>> we have a better code. > >>> > >>>>> Boot log from Lenovo Carbon X1 (7th gen) with the default settings: > >>>>> > >>>>> snd_hda_intel 0000:00:1f.3: Digital mics found on Skylake+ platform, aborting probe > >>>>> snd_soc_skl 0000:00:1f.3: SOF driver is preferred on this platform, aborting probe > >>>>> sof-audio-pci 0000:00:1f.3: warning: No matching ASoC machine driver found > >>>>> sof-audio-pci 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040380 > >>>>> .... > >>>>> > >>>>> Perhaps, it may be more wise to create one shared module and all > >>>>> three drivers should call the driver detection routine(s) from one > >>>>> place. > >>>> > >>>> We did look into this and it's a bit complicated in terms of plumbing. > >>> > >>> Could you elaborate more here? I believe that for the runtime environment > >>> where all drivers are compiled in the kernel, it might make sense to have this > >>> code at one place and installed only once for all three (or may be four in the > >>> soundwire future) drivers. > >>> > >>> We should have one straight way which driver/module is used. The separate > >>> conditions in the mentioned drivers will cause problems. Also, it will > >>> simplify things for the end user. One module parameter (in the driver selector > >>> library) is better than three or four to make things working (if the DMI / > >>> whatever table is not preset correctly for the new hardware). > >> > >> Well, one question is where to put this option. I thought of HD-audio > >> core in the past, but it's not always the common place any longer. > >> We may introduce yet another common module just for an option, but it > >> sounds little appealing to me in comparison with the needed > >> resources. > >> > >> Basically the deployment of SST is only for the already existing > >> devices, and all newer should go for SOF. And, the pattern Pierre > >> mentioned should cover almost all use cases. This made me believing > >> that a simple switch is no mandatory request. > >> > >> In anyway, Jaroslav's patch looks like a good starting point. We can > >> build up a few more exceptions (SKl/KBl/APL Chromebooks with DMIC) on > >> top of it, then we've done mostly, right? > > > > Yes, there are only a handful of quirks really. > > It seems like a not very rubust solution for me. If you don't like to have > a standalone module, the code might be included to all drivers, but we losethe > possibility to control the auto detection behaviour from the one place > (one module parameter). > > Perhaps, we can rename snd_intel_nhlt() module and put the auto-detection code > there. It's required by all mentioned drivers, so the extra resources required > for this new code are minimal. I don't mind either way, as long as we don't need to introduce too complex new stuff just for that. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel