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=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 2F84AC433DF for ; Tue, 30 Jun 2020 14:16:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0B85E2074D for ; Tue, 30 Jun 2020 14:16:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593526569; bh=8k53/BoNXkzXn4m/rIfsN0pdXlVX6wTgTRKAHAP4dDE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=IuTW7T+RZC2C79kMrTfk/II4KI4LYLutGo6++oE1qjj0UCqjPEVBcvgSH/58+Z+7j eWgpuzzaWVtULw0J+29bihb1thByAjfpubGKtgGdzftTkSCrsY+LtYHyGvA2fF2aWr BWl+G8cOtCLbhZtiL6mvz6M2I2mfpnTEaR9nHv0Q= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726047AbgF3OQI (ORCPT ); Tue, 30 Jun 2020 10:16:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:53184 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725887AbgF3OQI (ORCPT ); Tue, 30 Jun 2020 10:16:08 -0400 Received: from localhost (fw-tnat.cambridge.arm.com [217.140.96.140]) (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 B8AD22072D; Tue, 30 Jun 2020 14:16:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593526567; bh=8k53/BoNXkzXn4m/rIfsN0pdXlVX6wTgTRKAHAP4dDE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=l6EXLMgweZ3EOC9BBkeDtlVppbrQ+3Hbz9Czewc6BUkFt9nnSmC9WSwm3ckV+RrTc V+BlmQzeQj2rtWi0KzQVcnSIg/4Edl39bUwxceZ0fAiROPTHt9j7AbbdzagOSih8UC fXn7u9aKT7VIdFf7SojkpPWLX9begFISkifh7UOI= Date: Tue, 30 Jun 2020 15:16:04 +0100 From: Mark Brown To: Jason Gunthorpe Cc: Greg KH , Takashi Iwai , Pierre-Louis Bossart , Ranjani Sridharan , Jeff Kirsher , davem@davemloft.net, netdev@vger.kernel.org, linux-rdma@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com, Fred Oh , lee.jones@linaro.org Subject: Re: [net-next v4 10/12] ASoC: SOF: Introduce descriptors for SOF client Message-ID: <20200630141604.GJ5272@sirena.org.uk> References: <20200523062351.GD3156699@kroah.com> <57185aae-e1c9-4380-7801-234a13deebae@linux.intel.com> <20200524063519.GB1369260@kroah.com> <20200527071733.GB52617@kroah.com> <20200629203317.GM5499@sirena.org.uk> <20200629225959.GF25301@ziepe.ca> <20200630103141.GA5272@sirena.org.uk> <20200630113245.GG25301@ziepe.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BEa57a89OpeoUzGD" Content-Disposition: inline In-Reply-To: <20200630113245.GG25301@ziepe.ca> X-Cookie: Walk softly and carry a megawatt laser. User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org --BEa57a89OpeoUzGD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 30, 2020 at 08:32:45AM -0300, Jason Gunthorpe wrote: > On Tue, Jun 30, 2020 at 11:31:41AM +0100, Mark Brown wrote: > > On Mon, Jun 29, 2020 at 07:59:59PM -0300, Jason Gunthorpe wrote: > > > > What are we supposed to do with things like PCI attached FPGAs and = ASICs > > > > in that case? They can have host visible devices with physical > > > > resources like MMIO ranges and interrupts without those being split= up > > > > neatly as PCI subfunctions - the original use case for MFD was such > > > > ASICs, there's a few PCI drivers in there now.=20 > > > Greg has been pretty clear that MFD shouldn't have been used on top of > > > PCI drivers. > > The proposed bus lacks resource handling, an equivalent of > > platform_get_resource() and friends for example, which would be needed > > for use with physical devices. Both that and the name suggest that it's > > for virtual devices. > Resource handling is only useful if the HW has a hard distinction > between it's functional blocks. This scheme is intended for devices > where that doesn't exist. The driver that attaches to the PCI device > and creates the virtual devices is supposed to provide SW abstractions > for the other drivers to sit on. > I'm not sure why we are calling it virtual bus. The abstraction that the PCI based MFDs (and FPGAs will be similar, they're just dynamic MFDs to a good approximation) need is to pass through MMIO regions, interrupts and so on which is exactly what the platform bus offers. The hardware is basically someone taking a bunch of IPs and shoving them behind the MMIO/interrupt regions of a PCI device. > > The reason the MFDs use platform devices is that they end up having to > > have all the features of platform devices - originally people were > > making virtual buses for them but the code duplication is real so > > everyone (including Greg) decided to just use what was there already. > Maybe Greg will explain why he didn't like the earlier version of that > stuff that used MFD AFAICT Greg is mostly concerned about the MFDs that aren't memory mapped, though some of them do use the resource API to pass interrupts through. --BEa57a89OpeoUzGD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl77SSMACgkQJNaLcl1U h9AGsQf/YwRWc++R3JTLbJIAO1diptlxzOjkcoVBbRynI0tEvfr93ORaWOdFn8xX L5BNjAdaZWZXZYQNQCFDLy6Zl72+DRbpOpJD8E7CuClb7r+P3cz9EBA6pkBneSAo 6CHLBLOEzxRan6CfIcoGxcAzaWI+RakMgq6ZGvkhkduyVudgS+g1zajubT8vij4K UhK2cW3ZotUrKc8Kr7DysDgUd8l5/p9tZH1OwIyC4j8Y2Z3AHQsi/4uOMyiKoZgN z1PF/tllaixdbDz/V8NOk5qD7wvKMqvg88Zzfl1turrWMMrtBHl9l/o2L30Mv2iZ LTk4XynmKQSpqpdBHl1+VqZx3rMzfQ== =eAIK -----END PGP SIGNATURE----- --BEa57a89OpeoUzGD--