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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 A3021C433DB for ; Tue, 12 Jan 2021 13:56:37 +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 0E5E02310A for ; Tue, 12 Jan 2021 13:56:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0E5E02310A 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 0633C16B2; Tue, 12 Jan 2021 14:55:45 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 0633C16B2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1610459795; bh=yJ6ij6dkqXQWN87kA5/GcS4MxHPMjelWV7OmYl0WKj8=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=lxVA5oYbV3efr73O3Vt0nOQ0jlzjOfBnpEuPBYXm/r1QB0AdsHdkG6LjtbyOAOUH8 EhV8/fchnrw797TaEK8F2nRMPc75CDBAh/kFJJef/rY8o8YG3FTJiKEBHI0TrmWCU3 Sx1CvXlv8wF8Jx6pZduNhsO1LTQ+Ed1aCLBdz3t0= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 98360F800B9; Tue, 12 Jan 2021 14:55:44 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 099AAF8025E; Tue, 12 Jan 2021 14:55:43 +0100 (CET) Received: from mx2.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 3BB76F800B9; Tue, 12 Jan 2021 14:55:32 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 3BB76F800B9 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 5B24AAC8F; Tue, 12 Jan 2021 13:55:32 +0000 (UTC) Date: Tue, 12 Jan 2021 14:55:31 +0100 Message-ID: From: Takashi Iwai To: Pierre-Louis Bossart Subject: Re: [PATCH] ASoC: SOF: Intel: avoid reverse module dependency In-Reply-To: <59a36212-2412-2dd3-62f2-69c6f65312b1@linux.intel.com> References: <20210105190808.613050-1-arnd@kernel.org> <59a36212-2412-2dd3-62f2-69c6f65312b1@linux.intel.com> 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") Content-Type: text/plain; charset=US-ASCII Cc: Arnd Bergmann , ALSA Development Mailing List , Kai Vehmanen , Arnd Bergmann , "linux-kernel @ vger . kernel . org" , Takashi Iwai , YueHaibing , Liam Girdwood , Mark Brown , Ranjani Sridharan , Daniel Baluta , sound-open-firmware@alsa-project.org 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: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Mon, 11 Jan 2021 20:54:17 +0100, Pierre-Louis Bossart wrote: > > > > On 1/5/21 1:07 PM, Arnd Bergmann wrote: > > From: Arnd Bergmann > > > > The SOF-ACPI driver is backwards from the normal Linux model, it has a > > generic driver that knows about all the specific drivers, as opposed to > > having hardware specific drivers that link against a common framework. > > > > This requires ugly Kconfig magic and leads to missed dependencies as > > seen in this link error: > > > > arm-linux-gnueabi-ld: sound/soc/sof/sof-pci-dev.o: in function `sof_acpi_probe': > > sof-pci-dev.c:(.text+0x1c): undefined reference to `snd_intel_dsp_driver_probe' > > > > Change it to use the normal probe order of starting with a specific > > device in a driver, turning the sof-acpi-dev.c driver into a library. > > Thanks Arnd for reporting all this, much appreciated. > > The initial design was that we would have one generic platform_driver > (ACPI) and one generic PCI driver that would deal with all known IDs, > with descriptors that would point ops and callbacks defined in > device-specific drivers. It's how all Intel drivers worked so far, > from HDaudio to Atom/SST and Skylake. > > It's not that ugly, but to Arnd's point we do have a lot of #if > IS_ENABLED at the top level with a larger and larger table of IDs, > along with Kconfig magic indeed to propagate constraints from > top-level to device-specific drivers. The error with DSP_CONFIG comes > from the fact that this never belonged at the top-level, or should > have been conditionally invoked, as noted by Takashi. > > That said, the initial design which dates from 2017 can be revisited > now that we start having quite a few platforms and more coming. What > Arnd suggests isn't without merits, it would indeed turn the generic > code into generic helpers, and have all the platform IDs maintained in > device-specific drivers. It's a more distributed/scalable solution, > the only minor drawback I see is that it would require multiple > instances of the 'platform_driver' and 'pci_driver' structures. > > I would also want to keep the top-level selection so that ACPI/PCI/DT > modules can be disabled in one shot, that would mean an additional > change to the Makefiles since e.g. > obj-$(CONFIG_SND_SOC_SOF_ACPI) += snd-sof-acpi.o > would need to be set somehow. > > Since this is going to be a really invasive change, and past > experience shows that mucking with Kconfigs will invariably raise a > number of broken corner cases, if there is support from > Mark/Takashi/Jaroslav on this idea, we should first test it in the SOF > tree so that we get a good test coverage and don't break too many eggs > in Mark's tree. We would also need to concurrently change our CI > scripts which are dependent on module names. I'm in favor of the way Arnd proposed. It's more straightforward and less code. If you find the number of modules or the too much cutting out being problematic, you can create a module snd-sof-intel-acpi and snd-sof-intel-pci containing the driver table entries for all Intel devices, too. In the case, you'll still need some conditional calls of intel-dsp-config there, but it's a good step for reducing the Kconfig complexity. > Also maybe in a first pass we can remove the compilation error with > IS_REACHABLE and in a second pass do more invasive surgery? Agreed, we'd like to keep less changes for 5.11 for now. thanks, Takashi