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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 55835C3B1B1 for ; Fri, 14 Feb 2020 17:50:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 290CA206B6 for ; Fri, 14 Feb 2020 17:50:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390256AbgBNRuB (ORCPT ); Fri, 14 Feb 2020 12:50:01 -0500 Received: from foss.arm.com ([217.140.110.172]:42128 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388732AbgBNRt6 (ORCPT ); Fri, 14 Feb 2020 12:49:58 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5B8E1328; Fri, 14 Feb 2020 09:49:57 -0800 (PST) Received: from e121166-lin.cambridge.arm.com (e121166-lin.cambridge.arm.com [10.1.196.255]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 157803F68E; Fri, 14 Feb 2020 09:49:53 -0800 (PST) Date: Fri, 14 Feb 2020 17:49:49 +0000 From: Lorenzo Pieralisi To: Pankaj Bansal Cc: Marc Zyngier , Ard Biesheuvel , Makarand Pawagi , Calvin Johnson , "stuyoder@gmail.com" , "nleeder@codeaurora.org" , Ioana Ciornei , Cristi Sovaiala , Hanjun Guo , Will Deacon , "jon@solid-run.com" , Russell King , ACPI Devel Maling List , Len Brown , Jason Cooper , Andy Wang , Varun Sethi , Thomas Gleixner , linux-arm-kernel , Laurentiu Tudor , Paul Yang , "netdev@vger.kernel.org" , "Rafael J. Wysocki" , Linux Kernel Mailing List , Shameerali Kolothum Thodi , Sudeep Holla , Robin Murphy Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc Message-ID: <20200214174949.GA30484@e121166-lin.cambridge.arm.com> References: <1580198925-50411-1-git-send-email-makarand.pawagi@nxp.com> <20200128110916.GA491@e121166-lin.cambridge.arm.com> <12531d6c569c7e14dffe8e288d9f4a0b@kernel.org> <7349fa0e6d62a3e0d0e540f2e17646e0@kernel.org> <20200214161957.GA27513@e121166-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 14, 2020 at 04:35:10PM +0000, Pankaj Bansal wrote: [...] > > -----Original Message----- > > From: Lorenzo Pieralisi > > Sent: Friday, February 14, 2020 9:50 PM > > To: Pankaj Bansal > > Cc: Marc Zyngier ; Ard Biesheuvel > > ; Makarand Pawagi ; > > Calvin Johnson ; stuyoder@gmail.com; > > nleeder@codeaurora.org; Ioana Ciornei ; Cristi > > Sovaiala ; Hanjun Guo ; > > Will Deacon ; jon@solid-run.com; Russell King > > ; ACPI Devel Maling List ; > > Len Brown ; Jason Cooper ; Andy > > Wang ; Varun Sethi ; Thomas > > Gleixner ; linux-arm-kernel > kernel@lists.infradead.org>; Laurentiu Tudor ; Paul > > Yang ; netdev@vger.kernel.org; Rafael J. Wysocki > > ; Linux Kernel Mailing List ; > > Shameerali Kolothum Thodi ; > > Sudeep Holla ; Robin Murphy > > > > Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc Side note: would you mind removing the email headers (as above) in your replies please ? > > On Fri, Feb 14, 2020 at 03:58:14PM +0000, Pankaj Bansal wrote: > > > > [...] > > > > > > Why should the device know about its own ID? That's a bus/interconnect > > thing. > > > > And nothing should be passed *to* IORT. IORT is the source. > > > > > > IORT is translation between Input IDs <-> Output IDs. The Input ID is still > > expected to be passed to parse IORT table. > > > > Named components use an array of single mappings (as in entries with single > > mapping flag set) - Input ID is irrelevant. > > > > Not sure what your named component is though and what you want to do with > > it, the fact that IORT allows mapping for named components do not necessarily > > mean that it can describe what your system really is, on that you need to > > elaborate for us to be able to help. > > Details about MC bus can be read from here: > https://elixir.bootlin.com/linux/latest/source/Documentation/networking/device_drivers/freescale/dpaa2/overview.rst#L324 > > As stated above, in Linux MC is a bus (just like PCI bus, AMBA bus etc) > There can be multiple devices attached to this bus. Moreover, we can dynamically create/destroy these devices. > Now, we want to represent this BUS (not individual devices connected to bus) in IORT table. > The only possible way right now we see is that we describe it as Named components having a pool of ID mappings. > As and when devices are created and attached to bus, we sift through this pool to correctly determine the output ID for the device. > Now the input ID that we provide, can come from device itself. > Then we can use the Platform MSI framework for MC bus devices. So are you asking me if that's OK ? Or there is something you can't describe with IORT ? Side note: can you explain to me please how the MSI allocation flow and kernel data structures/drivers are modeled in DT ? I had a quick look at: drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c and to start with, does that code imply that we create a DOMAIN_BUS_FSL_MC_MSI on ALL DT systems with an ITS device node ? I *think* you have a specific API to allocate MSIs for MC devices: fsl_mc_msi_domain_alloc_irqs() which hook into the IRQ domain created in the file above that handles the cascading to an ITS domain, correct ? Thanks, Lorenzo