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=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=unavailable 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 B8EE9C43218 for ; Fri, 26 Apr 2019 09:56:06 +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 8774920679 for ; Fri, 26 Apr 2019 09:56:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="JgKOx0nb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8774920679 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=csgraf.de 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:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=aEYmQd/LSXRAWslJTfE9B8F/loh6Po601gmz/06Q2Lw=; b=JgKOx0nb3Iuyqe Nj59BYp3EIiT02zmD0XWn3zXONpCjaXKZIT0xHzYBef9b+d3JdKlX1tM+UCuieveftb4mQionCSgT ygCQ6fg3ASRotlB+h2l1l/YYxU/mDaBJWh81aXQ7kpmEnQUeSa46cadXI7xwQlbg62cKEqGWtn8bP 1zHU+1033u7aCJsOGf2pH4RFi1I8qmZ3jL3L+7nipd0tcDlS8+ajM67jvG7nxYzDpUFtfkFLHnlk9 ek8RLT6QRTObCVNdDb44aEO3aur/2AKu8cw/og5RJEjFEx0aV/gksofbp/fCo6oyVznb9oQ3JNUMh lg2+Wb8tz/mDco7h6GUw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hJxaL-0003Hu-Bp; Fri, 26 Apr 2019 09:56:01 +0000 Received: from zulu616.server4you.de ([188.138.100.120]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hJxaH-0003H9-Ja for linux-arm-kernel@lists.infradead.org; Fri, 26 Apr 2019 09:55:59 +0000 Received: from macbook-2.local (x4d092da9.dyn.telefonica.de [77.9.45.169]) by csgraf.de (Postfix) with ESMTPSA id C037439003CF; Fri, 26 Apr 2019 11:49:06 +0200 (CEST) Subject: Re: [PATCH 7/7] irqchip/al-msi: Add ACPI support To: Marc Zyngier , Zeev Zilberman , Hanna Hawa References: <1554035733-11827-1-git-send-email-hhhawa@amazon.com> <1554035733-11827-3-git-send-email-hhhawa@amazon.com> <86pnq65v48.wl-marc.zyngier@arm.com> From: Alexander Graf Message-ID: Date: Fri, 26 Apr 2019 11:49:06 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190426_025557_944280_90F97E3B X-CRM114-Status: GOOD ( 16.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arm-kernel@lists.infradead.org, barakw@amazon.com, Lorenzo Pieralisi , linux-kernel@vger.kernel.org, jason@lakedaemon.net, antoine.tenart@bootlin.com, catalin.marinas@arm.com, vaerov@amazon.com, rjw@rjwysocki.net, linux@armlinux.org.uk, will.deacon@arm.com, hanochu@amazon.com, linux-acpi@vger.kernel.org, alisaidi@amazon.com, jonnyc@amazon.com, ronenk@amazon.com, tglx@linutronix.de, lenb@kernel.org, talel@amazon.com, dwmw@amazon.co.uk, tsahee@annapurnalabs.com 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 12.04.19 14:08, Marc Zyngier wrote: > Hi Zeev, > > On 04/04/2019 15:45, Zeev Zilberman wrote: >> Hi Marc, >> >> We have considered exposing our interrupt controller both via MADT >> OEM-specific entry and via DSDT. >> We've chosen MADT OEM-specific entry, because it seemed like a >> reasonable placeholder for custom interrupt controller, but we can move >> to DSDT, if this seems like a better way to represent it. >> >> Either way we chose, we'll need to solve the ordering issue of the >> drivers probing. >> The desired order of driver probing in the system, because of the >> dependencies, is: >> GIC -> AL MSIX controller driver -> PCI >> If we keep using MADT, we can't just use IRQCHIP_DECLARE, because there >> is no way we found to control ordering of MADT probing. So, GIC might be >> probed after our driver in this case. >> The reason we used early_initcall, is that the early_initcalls are >> invoked after MADT probing in the system (and before DSDT probing). >> >> If we move to using DSDT we need to solve the ordering problem from >> another direction - make sure that MSIX driver is probed before PCI. >> In the patches that were posted for xgene interrupt controller (and >> weren't accepted) we saw that they proposed to solve the same issue >> by modifying ACPI subsystem code by defining a new type for msi drivers >> and probing them before PCI drivers >> (https://patchwork.ozlabs.org/patch/818771/). >> From the feedback on that patch >> (https://patchwork.ozlabs.org/cover/818767/#1788415) it seemed that >> alternative solution is in the works, >> but we didn't manage to find any followup on this. >> >> We would be glad to hear what you propose for fixing the ordering issue >> and rework the patches accordingly. > > There are multiple issues here, but the main one is that you're trying > to do something that is completely contrary to the ACPI spec by > inventing a new interrupt controller. > > The use case for ACPI is quite simple: you have HW that matches the ACPI > spec, and everything will work out of the box. This means GICv2+GICv2m > or GICv3+ITS. There is zero space for creativity. Now, if you want your > own interrupt controller, the only choice is to stick with DT. That's > the place for weird and wonderful stuff that ACPI cannot support. I've had a quick chat about this with Marc at Linaro Connect and there might be a 3rd viable option: Create a standard ACPI binding for GICv3+MBI (akin to GICv2m) and use that. Zeev, Hanna, what exactly is the reason you need to use your own MSI translation engine here? Can't you just reuse the GICv3 built-in one? After all, I would assume that your PCIe complex is able to send DMA requests to external devices? If you could, we could start working towards an ACPI definition for that instead and make everyone happy. Alex _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel