From patchwork Tue Aug 30 10:08:34 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lorenzo Pieralisi X-Patchwork-Id: 9305151 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 7E30A607F0 for ; Tue, 30 Aug 2016 10:08:33 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6EFF62864F for ; Tue, 30 Aug 2016 10:08:33 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6349C28AF2; Tue, 30 Aug 2016 10:08:33 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3761828AD2 for ; Tue, 30 Aug 2016 10:08:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757721AbcH3KI3 (ORCPT ); Tue, 30 Aug 2016 06:08:29 -0400 Received: from foss.arm.com ([217.140.101.70]:35714 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755725AbcH3KI2 (ORCPT ); Tue, 30 Aug 2016 06:08:28 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 56D42349; Tue, 30 Aug 2016 03:08:27 -0700 (PDT) Received: from red-moon (red-moon.cambridge.arm.com [10.1.206.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C31C53F32C; Tue, 30 Aug 2016 03:08:25 -0700 (PDT) Date: Tue, 30 Aug 2016 11:08:34 +0100 From: Lorenzo Pieralisi To: Sinan Kaya Cc: Marc Zyngier , Duc Dang , Bjorn Helgaas , Rafael Wysocki , linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org, patches , Bjorn Helgaas , Punit Agrawal Subject: Re: Defining polarity and trigger mode for static interrupts in _PRT Message-ID: <20160830100834.GA368@red-moon> References: <20160824213005.1a9300ef@arm.com> <20160825121825.322d8450@arm.com> <20160825195917.0e75a8db@arm.com> <20160826090813.GA1038@red-moon> <20160826130832.2fde2327@arm.com> <20160826170615.GC23885@red-moon> <66f94732-7ce4-e577-9bec-52f0dc8e6ddb@codeaurora.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <66f94732-7ce4-e577-9bec-52f0dc8e6ddb@codeaurora.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Fri, Aug 26, 2016 at 06:53:29PM -0400, Sinan Kaya wrote: > > >> Let me throw option d here. > >> > >> I know Bjorn wants to keep ACTIVE_LOW in the code for common code but > >> can't we override this in an arch specific way (arm64's pci.c) while > >> creating the root bridge? > > > > On what basis ? You were not copied in from the beginning, but that > > is not different from Duc's initial proposal, which Marc discarded > > because it should not be done at arch level, it depends on the interrupt > > controller. > > I happen to watch the linux-pci and linux-acpi mail-lists. I also saw > Duc's initial proposal. > > I can't imagine someone building an ACPI compliant ARM64 platform > without a GIC interrupt controller. > > The SBSA spec already mentions what kind of compatibility should be > maintained with respect to GIC. You can't have an ACPI system that's > SBSA compliant and not using GIC. > > Can't we just hard code this to ACTIVE_HIGH in arch directory if ACPI > is defined. Why do we have to reach out to the interrupt controller? Patch below (horrible but no solution will be shiny either). > https://lists.linaro.org/pipermail/linaro-acpi/2015-November/005973.html [...] > If you look at my email above, I tried getting rid of PCI Link object > and I couldn't. I sticked to only thing that works. That's what I object to. If the ACPI bindings do not work for ARM we do not work around issues, we upgrade the specs because what may work for you has to work on all ARM platforms (and all FW developers have to be aware of that). Granted, this is a tiny snag, but the point is that no one knows what's the correct way of describing PCI legacy IRQs on ARM and we need that rectified. This does the trick for me (I can turn it into a function/look-up that returns the polarity), I am sure it will ruffle feathers but we have to find a solution so here it is (that acpi_irq_model gem is already used in generic code drivers/acpi/pci_link.c ;-)) -- >8 -- --- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c index 2c45dd3..c9b8c85 100644 --- a/drivers/acpi/pci_irq.c +++ b/drivers/acpi/pci_irq.c @@ -411,7 +411,8 @@ int acpi_pci_irq_enable(struct pci_dev *dev) int gsi; u8 pin; int triggering = ACPI_LEVEL_SENSITIVE; - int polarity = ACPI_ACTIVE_LOW; + int polarity = acpi_irq_model == ACPI_IRQ_MODEL_GIC ? + ACPI_ACTIVE_HIGH : ACPI_ACTIVE_LOW; char *link = NULL; char link_desc[16]; int rc;