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,URIBL_BLOCKED,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 21B50C34022 for ; Mon, 17 Feb 2020 15:25:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EB51720801 for ; Mon, 17 Feb 2020 15:25:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728631AbgBQPZ2 (ORCPT ); Mon, 17 Feb 2020 10:25:28 -0500 Received: from foss.arm.com ([217.140.110.172]:37308 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727553AbgBQPZ2 (ORCPT ); Mon, 17 Feb 2020 10:25:28 -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 8B69030E; Mon, 17 Feb 2020 07:25:27 -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 41D553F703; Mon, 17 Feb 2020 07:25:24 -0800 (PST) Date: Mon, 17 Feb 2020 15:25:18 +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: <20200217152518.GA18376@e121166-lin.cambridge.arm.com> References: <12531d6c569c7e14dffe8e288d9f4a0b@kernel.org> <7349fa0e6d62a3e0d0e540f2e17646e0@kernel.org> <20200214161957.GA27513@e121166-lin.cambridge.arm.com> <20200214174949.GA30484@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-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Mon, Feb 17, 2020 at 12:35:12PM +0000, Pankaj Bansal wrote: > > > > -----Original Message----- > > From: Lorenzo Pieralisi > > Sent: Friday, February 14, 2020 11:20 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 > > > > 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 > acpi@vger.kernel.org>; > > > > 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 > kernel@vger.kernel.org>; > > > > 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 ? Read the question above please. [...] > > > 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 ? > > I am asking if that would be acceptable? > i.e. we represent MC bus as Named component is IORT table with a pool of IDs (without single ID mapping flag) > and then we use the Platform MSI framework for all children devices of MC bus. > Note that it would require the Platform MSI layer to correctly pass an input id for a platform device to IORT layer. How is this solved in DT ? You don't seem to need any DT binding on top of the msi-parent property, which is equivalent to IORT single mappings AFAICS so I would like to understand the whole DT flow (so that I understand how this FSL bus works) before commenting any further. > And IORT layer ought to retrieve the output id based on single ID mapping flag as well as input id. > > > > > 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 ? > > Yes. It's being done for all DT systems having ITS node. This does not seem correct to me, I will let Marc comment on the matter. > The domain creation is handled in drivers/bus/fsl-mc/fsl-mc-msi.c Thanks, Lorenzo 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.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,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 43C47C34022 for ; Mon, 17 Feb 2020 15:25:37 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 100B7215A4 for ; Mon, 17 Feb 2020 15:25:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="LAONkuyN" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 100B7215A4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=5aJ3F9q0VroapdI3hC6h3dh1PxgqdKr+W6wDxmbvgCc=; b=LAONkuyNATjjMw Xf53zcX8+3IkEQIjd2DXNxZtGl8lty7JH9aeOeDubQdirfr8xoOHWghQvgzQ806Yhn/jo+BvLNrMs ilgiOmFV7icA+d7oRItKJnFDMn+8/5xoRMAN9mx6L3/3+hrTVhcnv7EN1fc3BGpWfQ/pVTa37XBWJ j9eyXhx76MpXLFN0Ql1kcyu3BIvNXluEIG1R1i4hexOtEySjlygIR1x967hmGuFNK30AFQfXDlJEK yoYBtY7vInLISx/j50pRkwFTPd85Ef6+QY1iG+tqcJDJ0uWE27Lnvz2VbEHlrG//kAayI0RfcNIv2 5nnxNQpAO9xHMZJwJpCg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1j3iH5-0002vo-H1; Mon, 17 Feb 2020 15:25:31 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1j3iH2-0002vM-D0 for linux-arm-kernel@lists.infradead.org; Mon, 17 Feb 2020 15:25:29 +0000 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 8B69030E; Mon, 17 Feb 2020 07:25:27 -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 41D553F703; Mon, 17 Feb 2020 07:25:24 -0800 (PST) Date: Mon, 17 Feb 2020 15:25:18 +0000 From: Lorenzo Pieralisi To: Pankaj Bansal Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc Message-ID: <20200217152518.GA18376@e121166-lin.cambridge.arm.com> References: <12531d6c569c7e14dffe8e288d9f4a0b@kernel.org> <7349fa0e6d62a3e0d0e540f2e17646e0@kernel.org> <20200214161957.GA27513@e121166-lin.cambridge.arm.com> <20200214174949.GA30484@e121166-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200217_072528_529788_7295AD0A X-CRM114-Status: GOOD ( 23.31 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Calvin Johnson , "stuyoder@gmail.com" , "nleeder@codeaurora.org" , Ioana Ciornei , Cristi Sovaiala , Hanjun Guo , Will Deacon , Marc Zyngier , "jon@solid-run.com" , Russell King , ACPI Devel Maling List , Len Brown , Jason Cooper , Andy Wang , Makarand Pawagi , Varun Sethi , Thomas Gleixner , linux-arm-kernel , Laurentiu Tudor , Paul Yang , Ard Biesheuvel , "netdev@vger.kernel.org" , "Rafael J. Wysocki" , Linux Kernel Mailing List , Shameerali Kolothum Thodi , Sudeep Holla , Robin Murphy Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Feb 17, 2020 at 12:35:12PM +0000, Pankaj Bansal wrote: > > > > -----Original Message----- > > From: Lorenzo Pieralisi > > Sent: Friday, February 14, 2020 11:20 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 > > > > 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 > acpi@vger.kernel.org>; > > > > 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 > kernel@vger.kernel.org>; > > > > 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 ? Read the question above please. [...] > > > 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 ? > > I am asking if that would be acceptable? > i.e. we represent MC bus as Named component is IORT table with a pool of IDs (without single ID mapping flag) > and then we use the Platform MSI framework for all children devices of MC bus. > Note that it would require the Platform MSI layer to correctly pass an input id for a platform device to IORT layer. How is this solved in DT ? You don't seem to need any DT binding on top of the msi-parent property, which is equivalent to IORT single mappings AFAICS so I would like to understand the whole DT flow (so that I understand how this FSL bus works) before commenting any further. > And IORT layer ought to retrieve the output id based on single ID mapping flag as well as input id. > > > > > 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 ? > > Yes. It's being done for all DT systems having ITS node. This does not seem correct to me, I will let Marc comment on the matter. > The domain creation is handled in drivers/bus/fsl-mc/fsl-mc-msi.c Thanks, Lorenzo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel