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,URIBL_BLOCKED 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 D3E79C4361B for ; Fri, 18 Dec 2020 17:16:44 +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 35BBA23B53 for ; Fri, 18 Dec 2020 17:16:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 35BBA23B53 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bootlin.com 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 890201775; Fri, 18 Dec 2020 18:15:50 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 890201775 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1608311800; bh=T/kNWN51pLhBnpdDJ9y7r2j4kibYMrvL9roUbf9uJWw=; h=Date:From:To:Subject:References:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=mRIhmo2PTnSn/cbhjFjnv09Iup93E3TeC2yz80wlMp/MsBGCMwuuS1iYH2Y2wgpa2 0OeSbhSYAKH1u/U8kAtf5oKDOXf5TN/PUoBr0P/eMTcBwWr87NVLbPenyn9t5tznUv Zy0D6XIRvqvDtslCiOL0uWEOD1ioNw9XMbLaha9o= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id EE79BF80103; Fri, 18 Dec 2020 18:15:49 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id A77E1F801F7; Fri, 18 Dec 2020 18:15:48 +0100 (CET) Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 8B06CF80103 for ; Fri, 18 Dec 2020 18:15:37 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 8B06CF80103 X-Originating-IP: 86.202.109.140 Received: from localhost (lfbn-lyo-1-13-140.w86-202.abo.wanadoo.fr [86.202.109.140]) (Authenticated sender: alexandre.belloni@bootlin.com) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 780871BF207; Fri, 18 Dec 2020 17:15:34 +0000 (UTC) Date: Fri, 18 Dec 2020 18:15:34 +0100 From: Alexandre Belloni To: Jason Gunthorpe Subject: Re: [resend/standalone PATCH v4] Add auxiliary bus support Message-ID: <20201218171534.GF3143569@piout.net> References: <160695681289.505290.8978295443574440604.stgit@dwillia2-desk3.amr.corp.intel.com> <20201217211937.GA3177478@piout.net> <20201218131709.GA5333@sirena.org.uk> <20201218140854.GW552508@nvidia.com> <20201218155204.GC5333@sirena.org.uk> <20201218162817.GX552508@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201218162817.GX552508@nvidia.com> Cc: alsa-devel@alsa-project.org, lee.jones@linaro.org, Linux Kernel Mailing List , Kiran Patil , David Miller , linux-rdma , Greg KH , Martin Habets , Pierre-Louis Bossart , Liam Girdwood , Fred Oh , Mark Brown , Ranjani Sridharan , Jakub Kicinski , Dave Ertman , Dan Williams , Shiraz Saleem , Netdev , Leon Romanovsky , Parav Pandit 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 18/12/2020 12:28:17-0400, Jason Gunthorpe wrote: > On Fri, Dec 18, 2020 at 03:52:04PM +0000, Mark Brown wrote: > > On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote: > > > On Fri, Dec 18, 2020 at 01:17:09PM +0000, Mark Brown wrote: > > > > > > As previously discussed this will need the auxilliary bus extending to > > > > support at least interrupts and possibly also general resources. > > > > > I thought the recent LWN article summed it up nicely, auxillary bus is > > > for gluing to subsystems together using a driver specific software API > > > to connect to the HW, MFD is for splitting a physical HW into disjoint > > > regions of HW. > > > > This conflicts with the statements from Greg about not using the > > platform bus for things that aren't memory mapped or "direct firmware", > > a large proportion of MFD subfunctions are neither at least in so far as > > I can understand what direct firmware means. > > I assume MFD will keep existing and it will somehow stop using > platform device for the children it builds. > > That doesn't mean MFD must use aux device, so I don't see what you > mean by conflicts? > > If someone has a PCI device and they want to split it up, they should > choose between aux device and MFD (assuming MFD gets fixed, as Greg > has basically blanket NAK'd adding more of them to MFD as is) > I have an SoC with for example, a designware SPI controller (handled by drivers/spi/spi-dw-mmio.c), a designware I2C controller (handled by drivers/i2c/busses/i2c-designware-platdrv.c). So, those are MMIO and described using device tree. On this particular SoC, I can disable the CPU and connect it to another SoC using PCIe. In that case it will expose one BAR, with all the HW IPs. The question here is why would I use something different from platform devices to register the SPI and I2C controllers? It seems that by using auxiliary devices, I would have to reinvent parsing device property and children/clients description. This isn't great from a code reuse perspective. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com 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, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 AB97BC2BBD5 for ; Fri, 18 Dec 2020 17:16:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 75AD623B7A for ; Fri, 18 Dec 2020 17:16:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729854AbgLRRQT (ORCPT ); Fri, 18 Dec 2020 12:16:19 -0500 Received: from relay8-d.mail.gandi.net ([217.70.183.201]:34059 "EHLO relay8-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727787AbgLRRQT (ORCPT ); Fri, 18 Dec 2020 12:16:19 -0500 X-Originating-IP: 86.202.109.140 Received: from localhost (lfbn-lyo-1-13-140.w86-202.abo.wanadoo.fr [86.202.109.140]) (Authenticated sender: alexandre.belloni@bootlin.com) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 780871BF207; Fri, 18 Dec 2020 17:15:34 +0000 (UTC) Date: Fri, 18 Dec 2020 18:15:34 +0100 From: Alexandre Belloni To: Jason Gunthorpe Cc: Mark Brown , Greg KH , Dan Williams , Pierre-Louis Bossart , alsa-devel@alsa-project.org, Kiran Patil , linux-rdma , Shiraz Saleem , Martin Habets , Liam Girdwood , Ranjani Sridharan , Fred Oh , Dave Ertman , Jakub Kicinski , Netdev , Leon Romanovsky , David Miller , Linux Kernel Mailing List , Parav Pandit , lee.jones@linaro.org Subject: Re: [resend/standalone PATCH v4] Add auxiliary bus support Message-ID: <20201218171534.GF3143569@piout.net> References: <160695681289.505290.8978295443574440604.stgit@dwillia2-desk3.amr.corp.intel.com> <20201217211937.GA3177478@piout.net> <20201218131709.GA5333@sirena.org.uk> <20201218140854.GW552508@nvidia.com> <20201218155204.GC5333@sirena.org.uk> <20201218162817.GX552508@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201218162817.GX552508@nvidia.com> Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On 18/12/2020 12:28:17-0400, Jason Gunthorpe wrote: > On Fri, Dec 18, 2020 at 03:52:04PM +0000, Mark Brown wrote: > > On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote: > > > On Fri, Dec 18, 2020 at 01:17:09PM +0000, Mark Brown wrote: > > > > > > As previously discussed this will need the auxilliary bus extending to > > > > support at least interrupts and possibly also general resources. > > > > > I thought the recent LWN article summed it up nicely, auxillary bus is > > > for gluing to subsystems together using a driver specific software API > > > to connect to the HW, MFD is for splitting a physical HW into disjoint > > > regions of HW. > > > > This conflicts with the statements from Greg about not using the > > platform bus for things that aren't memory mapped or "direct firmware", > > a large proportion of MFD subfunctions are neither at least in so far as > > I can understand what direct firmware means. > > I assume MFD will keep existing and it will somehow stop using > platform device for the children it builds. > > That doesn't mean MFD must use aux device, so I don't see what you > mean by conflicts? > > If someone has a PCI device and they want to split it up, they should > choose between aux device and MFD (assuming MFD gets fixed, as Greg > has basically blanket NAK'd adding more of them to MFD as is) > I have an SoC with for example, a designware SPI controller (handled by drivers/spi/spi-dw-mmio.c), a designware I2C controller (handled by drivers/i2c/busses/i2c-designware-platdrv.c). So, those are MMIO and described using device tree. On this particular SoC, I can disable the CPU and connect it to another SoC using PCIe. In that case it will expose one BAR, with all the HW IPs. The question here is why would I use something different from platform devices to register the SPI and I2C controllers? It seems that by using auxiliary devices, I would have to reinvent parsing device property and children/clients description. This isn't great from a code reuse perspective. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com