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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 3DCCAC4332B for ; Fri, 20 Mar 2020 15:34:41 +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 BB0942070A for ; Fri, 20 Mar 2020 15:34:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="ptL/bp3D"; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Gtm7eDZ4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BB0942070A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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 14382823; Fri, 20 Mar 2020 16:33:49 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 14382823 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1584718479; bh=gPg6Rj9rfVl3kr0MPwORpU97iokmhn0TxIQRvdMirpw=; h=Date:From:To:Subject:References:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=ptL/bp3DiraZ8Snu87SYtkw9p6isGnooEc4Jpc040BJrG4T6267eTO8idEUfd0sVD RD2+c4Ru2p3bOTEsVUyVKX23n8cIaexrLwiYZgyo2rFcVItH6bLmMi138K7KpQry3M ypMzwMyKo173DzE6tFJRJFvW2KT4vs8BBZueFFj4= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 83DC8F80139; Fri, 20 Mar 2020 16:33:48 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id BFB9CF8015B; Fri, 20 Mar 2020 16:33:47 +0100 (CET) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id E1FEDF800C0 for ; Fri, 20 Mar 2020 16:33:44 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz E1FEDF800C0 Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Gtm7eDZ4" Received: from localhost (unknown [122.167.82.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DD54B2070A; Fri, 20 Mar 2020 15:33:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584718422; bh=gPg6Rj9rfVl3kr0MPwORpU97iokmhn0TxIQRvdMirpw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Gtm7eDZ4ul2aZhkwWfERCf2d8ES2RWgsn5LRSiSAvao2eRzLMh4FUMTqzPLEE+WNO KcMHbqpvZ7Xkc4uQtLVmgOc27GLBd8hZil0/fbdrww95gtU2+X6vXMf96TVJgMpxU4 cjT9on1SYCMidYkLDHQFI/gXP9Mj5vE/4sLO3gxI= Date: Fri, 20 Mar 2020 21:03:34 +0530 From: Vinod Koul To: Pierre-Louis Bossart Subject: Re: [PATCH 1/8] soundwire: bus_type: add master_device/driver support Message-ID: <20200320153334.GJ4885@vkoul-mobl> References: <20200305063646.GW4148@vkoul-mobl> <20200306050115.GC4148@vkoul-mobl> <4fabb135-6fbb-106f-44fd-8155ea716c00@linux.intel.com> <20200311063645.GH4885@vkoul-mobl> <0fafb567-10e5-a1ea-4a6d-b3c53afb215e@linux.intel.com> <20200313115011.GD4885@vkoul-mobl> <4cb16467-87d0-ef99-e471-9eafa9e669d2@linux.intel.com> <20200314094904.GP4885@vkoul-mobl> <3c32830c-cd12-867f-a763-7c3e385cb1e9@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3c32830c-cd12-867f-a763-7c3e385cb1e9@linux.intel.com> Cc: alsa-devel@alsa-project.org, tiwai@suse.de, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, Ranjani Sridharan , Hui Wang , broonie@kernel.org, srinivas.kandagatla@linaro.org, jank@cadence.com, slawomir.blauciak@intel.com, Sanyog Kale , Bard liao , Rander Wang 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 16-03-20, 14:15, Pierre-Louis Bossart wrote: > > > > > It's really down to your objection to the use of 'struct driver'... For ASoC > > > support we only need the .name and .pm_ops, so there's really no possible > > > path forward otherwise. > > > > It means that we cannot have a solution which is Intel specific into > > core. If you has a standalone controller you do not need this. > > A 'struct driver' is not Intel-specific, sorry. We are discussing 'struct sdw_master_driver'. Please be very specific in you replies and do not use incorrect terminology which confuses people. Sorry a 'struct sdw_master_driver' IMHO is. As I have said it is not needed if you have standalone controller even in Intel case, and rest of the world. > > > Like I said, we have 3 options > > > > Repeating the already discussed doesn't help. I have already told you the > > constraint to work is not to add Intel specific change into core. > > > > I have already said that expect the driver part I dont have objections > > to rest of this series and am ready to merge > > > > > a) stay with platform devices for now. You will need to have a conversation > > > with Greg on this. > > > > > > b) use a minimal sdw_master_device with a minimal 'struct driver' use. > > > > > > c) use a more elaborate solution suggested in this patchset and yes that > > > means the Qualcomm driver would need to change a bit. > > > > > > Pick one or suggest something that is implementable. The first version of > > > the patches was provided in October, the last RFC was provided on January > > > 31, time's up. At the moment you are preventing ASoC integration from moving > > > forward. > > > > In opensource review we go back and forth and we debate and come to a > > common conclusion. Choosing a specific set of solutions and constraining > > yourself to pick one does not help. > > First off, the ask to move away from platform devices came from Greg. Not > me. All I did here was suggest solutions, one reviewed by Greg as 'sane' and > 'nice work'. Greg essentially wrote the book on devices/drivers so his > review means I am not completely senile just yet. > > You pushed back with two proposals that don't account for power management > and the driver name required for ASoC. That was on top on another suggestion > to use platform devices that was shot down by Greg himself with language I > can't quote here. > > Please re-read my words: my ask was "Pick one or suggest something that is > implementable." IMO the path I suggested is implementable.. > > You don't pick one and don't suggest anything implementable either, so > there's really not much I can do, can I? I don't have a solution without a > 'struct driver', and you don't want it. > > The only short-term path forward I see is to ask Greg to agree to keep the > platform devices for now. And I guess you didn't talk to your Intel colleagues... Please talk to them on how they did it. > > > I have only _one_ constraint no platform specific change in core. If that > > is satisfied I will go with it. Sorry but this is non-negotiable for me. > > How is a 'struct driver' platform specific? > > > Ask yourself, do you need this intrusive core change if you had this > > exact same controller(s) but only as standalone one... > > That would really not change anything. There would be some sort of ID (PCI > or something else) for the controller and multiple masters below. The If it is single master? If it is multiple master with different ACPI ID for each master? Would you still need 'struct sdw_master_driver'? > ACPI/DisCo spec does not account for masters so they would have to be > created by hand. > > Again how is a 'struct driver' an 'intrusive change'? Again do not confuse by using incorrect terminology. Again 'struct sdw_master_driver' for a specific Intel hw configuration is. -- ~Vinod