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=-7.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham 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 05BE5C34026 for ; Tue, 18 Feb 2020 14:47:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D8DB52464E for ; Tue, 18 Feb 2020 14:47:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726663AbgBROrC (ORCPT ); Tue, 18 Feb 2020 09:47:02 -0500 Received: from foss.arm.com ([217.140.110.172]:53646 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726605AbgBROrC (ORCPT ); Tue, 18 Feb 2020 09:47:02 -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 413291FB; Tue, 18 Feb 2020 06:47:01 -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 EA7163F703; Tue, 18 Feb 2020 06:46:57 -0800 (PST) Date: Tue, 18 Feb 2020 14:46:53 +0000 From: Lorenzo Pieralisi To: "Pankaj Bansal (OSS)" Cc: Hanjun Guo , Marc Zyngier , Ard Biesheuvel , Makarand Pawagi , Calvin Johnson , "stuyoder@gmail.com" , "nleeder@codeaurora.org" , Ioana Ciornei , Cristi Sovaiala , 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: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc Message-ID: <20200218144653.GA4286@e121166-lin.cambridge.arm.com> References: <615c6807-c018-92c9-b66a-8afdda183699@huawei.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 Tue, Feb 18, 2020 at 12:48:39PM +0000, Pankaj Bansal (OSS) wrote: [...] > > > In DT case, we create the domain DOMAIN_BUS_FSL_MC_MSI for MC bus and > > it's children. > > > And then when MC child device is created, we search the "msi-parent" > > property from the MC > > > DT node and get the ITS associated with MC bus. Then we search > > DOMAIN_BUS_FSL_MC_MSI > > > on that ITS. Once we find the domain, we can call msi_domain_alloc_irqs for > > that domain. > > > > > > This is exactly what we tried to do initially with ACPI. But the searching > > DOMAIN_BUS_FSL_MC_MSI > > > associated to an ITS, is something that is part of drivers/acpi/arm64/iort.c. > > > (similar to DOMAIN_BUS_PLATFORM_MSI and DOMAIN_BUS_PCI_MSI) > > > > Can you have a look at mbigen driver (drivers/irqchip/irq-mbigen.c) to see if > > it helps you? > > > > mbigen is an irq converter to convert device's wired interrupts into MSI > > (connecting to ITS), which will alloc a bunch of MSIs from ITS platform MSI > > domain at the setup. > > Unfortunately this is not the same case as ours. As I see Hisilicon IORT table > Is using single id mapping with named components. > > https://github.com/tianocore/edk2-platforms/blob/master/Silicon/Hisilicon/Hi1616/D05AcpiTables/D05Iort.asl#L300 > > while we are not: > > https://source.codeaurora.org/external/qoriq/qoriq-components/edk2-platforms/tree/Platform/NXP/LX2160aRdbPkg/AcpiTables/Iort.aslc?h=LX2160_UEFI_ACPI_EAR1#n290 > > This is because as I said, we are trying to represent a bus in IORT > via named components and not individual devices connected to that bus. I had a thorough look into this and strictly speaking there is no *mapping* requirement at all, all you need to know is what ITS the FSL MC bus is mapping MSIs to. Which brings me to the next question (which is orthogonal to how to model FSL MC in IORT, that has to be discussed but I want to have a full picture in mind first). When you probe the FSL MC as a platform device, the ACPI core, through IORT (if you add the 1:1 mapping as an array of single mappings) already link the platform device to ITS platform device MSI domain (acpi_configure_pmsi_domain()). The associated fwnode is the *same* (IIUC) as for the DOMAIN_BUS_FSL_MC_MSI and ITS DOMAIN_BUS_NEXUS, so in practice you don't need IORT code to retrieve the DOMAIN_BUS_FSL_MC_MSI domain, the fwnode is the same as the one in the FSL MC platform device IRQ domain->fwnode pointer and you can use it to retrieve the DOMAIN_BUS_FSL_MC_MSI domain through it. Is my reading correct ? Overall, DOMAIN_BUS_FSL_MC_MSI is just an MSI layer to override the provide the MSI domain ->prepare hook (ie to stash the MC device id), no more (ie its_fsl_mc_msi_prepare()). That's it for the MSI layer - I need to figure out whether we *want* to extend IORT (and/or ACPI) to defined bindings for "additional busses", what I write above is a summary of my understanding, I have not made my mind up yet. As for the IOMMU code, it seems like the only thing needed is extending named components configuration to child devices, hierarchically. As Marc already mentioned, IOMMU and IRQ code must be separate for future postings but first we need to find a suitable answer to the problem at hand. Lorenzo