Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp1224594imj; Thu, 7 Feb 2019 20:33:53 -0800 (PST) X-Google-Smtp-Source: AHgI3IaBIc3t59waz6jiKdq+hI+DfQWUYs2gmVfR8+2dHmYb9vjRaPQJiZLMJI+DzM1r7sQl9aZD X-Received: by 2002:a63:f141:: with SMTP id o1mr3574378pgk.134.1549600433271; Thu, 07 Feb 2019 20:33:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549600433; cv=none; d=google.com; s=arc-20160816; b=L4HqTo9Vkd8RxyGeD4nIgC6EZccAasFJU+G3kYS3CmypNpYodh+LWVC6jWz+k4Ro0L 1wXNofOyiRO/8U1mfxv5ehZ0ihXwRi9DzuI4UsGzxIHL5zE6pCOosZh3ZTqiBaNPACGd DtvxQg/e/2CpNqly0f9TpXafUALYcAd9HB2Cz3j1BUmjYaz4SIAvqbioSVhWsNMHLZ18 V86gq1wjINLGbnYTP3kCWN5hRVWlPV+t4Rt9jicQ69dra+2/gXHEAdcMvPq3/S0btvfv nFOF0cy4jlg6lBLP0Q2JzKXKgpovv5a9QSlvjgiqgAPoHdzsNbkDQ7yfZgO8FleulLwq ulPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=v7CNHDwI7JL9k+8CJw1FIo64pVpyZaEbNQHdnQYswL8=; b=g9pu6QDwxJ63I2j0JZhGvSUqnY3jhpoBDvWkjAGG/S0hIh0wUH99edy3g5TIk4u4Dm VwF8I3Uv40iMDSk2riw9FqrNSFF8VtiDXz7GHSrcss+RLGWl7HxfREbOh7nHLJMStWfg JB/1Z071o2OKJLioVrHU3LelRANW9Ir+YKTZlKDbJvfzBUWEbNNiRYt1i9GeYc38UEZQ LiyAYvqy/8wR6Zq1iGlNFK2fM9z7SYQGHXaNLc1+8PiUBKAci19+Gysx+kLts3EToWXF fzPQghHd3pL0c4I4XckLwiREk7xyEkjuRVTfO/GjS2gZiEhifTacxmMfNLUhyB2/nn5s eXVA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=AoQ8p9HV; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d65si1056790pgc.213.2019.02.07.20.33.37; Thu, 07 Feb 2019 20:33:53 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=AoQ8p9HV; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727099AbfBHEcx (ORCPT + 99 others); Thu, 7 Feb 2019 23:32:53 -0500 Received: from lelv0142.ext.ti.com ([198.47.23.249]:40418 "EHLO lelv0142.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726793AbfBHEcx (ORCPT ); Thu, 7 Feb 2019 23:32:53 -0500 Received: from lelv0265.itg.ti.com ([10.180.67.224]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id x184WfSI073156; Thu, 7 Feb 2019 22:32:41 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1549600361; bh=v7CNHDwI7JL9k+8CJw1FIo64pVpyZaEbNQHdnQYswL8=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=AoQ8p9HVhHtStavIVBw5Jr9ppG7bik7KZORGFqivoMo98suQblvYqQX3or+UjeY9G jxt3upof9GP5o1BD6xrbRhcZ+PGdzY6rcAXBxyVvt7/JyUzBYL6OtWf2NUZ0wIxZSf n2Gc+lTZ3CONuMjVm0eOomZaP+xVEL4pUx3L04QA= Received: from DFLE113.ent.ti.com (dfle113.ent.ti.com [10.64.6.34]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id x184WfpB104629 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 7 Feb 2019 22:32:41 -0600 Received: from DFLE111.ent.ti.com (10.64.6.32) by DFLE113.ent.ti.com (10.64.6.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Thu, 7 Feb 2019 22:32:40 -0600 Received: from dlep33.itg.ti.com (157.170.170.75) by DFLE111.ent.ti.com (10.64.6.32) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1591.10 via Frontend Transport; Thu, 7 Feb 2019 22:32:40 -0600 Received: from [172.24.190.233] (ileax41-snat.itg.ti.com [10.172.224.153]) by dlep33.itg.ti.com (8.14.3/8.13.8) with ESMTP id x184WbF3015086; Thu, 7 Feb 2019 22:32:38 -0600 Subject: Re: [PATCH v2 2/9] PCI: keystone: Modify legacy_irq_handler to check the IRQ_STATUS of INTA/B/C/D To: Lorenzo Pieralisi CC: Murali Karicheri , Bjorn Helgaas , Jingoo Han , Gustavo Pimentel , , , References: <20190207110924.30716-1-kishon@ti.com> <20190207110924.30716-3-kishon@ti.com> <20190207161502.GC21111@e107981-ln.cambridge.arm.com> From: Kishon Vijay Abraham I Message-ID: <55d1eeef-e8a5-1801-96e7-3cfed8f756fe@ti.com> Date: Fri, 8 Feb 2019 10:02:05 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190207161502.GC21111@e107981-ln.cambridge.arm.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Lorenzo, On 07/02/19 9:45 PM, Lorenzo Pieralisi wrote: > On Thu, Feb 07, 2019 at 04:39:17PM +0530, Kishon Vijay Abraham I wrote: >> The legacy interrupt handler directly checks the IRQ_STATUS register >> corresponding to a interrupt line inorder to invoke generic_handle_irq. >> >> While this is okay for K2G platform which has separate interrupt line for >> each of the 4 legacy interrupts, AM654 which uses the same PCIe wrapper >> has a single interrupt line for all the legacy interrupts. So for AM654 >> the interrupt handler won't be able to directly check the IRQ_STATUS >> register corresponding to the interrupt line. >> >> Also the legacy interrupt handler uses 'virq' obtained from >> irq_of_parse_and_map to find the correct interrupt line which raised the >> interrupt. There is no guarantee that virq assigned for contiguous hardware >> irq will be contiguous and the interrupt handler might end up checking >> the wrong IRQ_STATUS register. >> >> In order to overcome the above issues, read the IRQ_STATUS register of >> all the 4 legacy interrupts to determine which interrupt was raised. >> >> Link: https://lkml.kernel.org/r/bb081d21-7c03-0357-4294-7e92d95d838c@arm.com >> Signed-off-by: Kishon Vijay Abraham I >> --- >> drivers/pci/controller/dwc/pci-keystone.c | 22 ++++++++++++---------- >> 1 file changed, 12 insertions(+), 10 deletions(-) >> >> diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c >> index 5286a480f76b..4cf9849d5a1d 100644 >> --- a/drivers/pci/controller/dwc/pci-keystone.c >> +++ b/drivers/pci/controller/dwc/pci-keystone.c >> @@ -214,16 +214,11 @@ static void ks_pcie_handle_legacy_irq(struct keystone_pcie *ks_pcie, >> { >> struct dw_pcie *pci = ks_pcie->pci; >> struct device *dev = pci->dev; >> - u32 pending; >> int virq; >> >> - pending = ks_pcie_app_readl(ks_pcie, IRQ_STATUS(offset)); >> - >> - if (BIT(0) & pending) { >> - virq = irq_linear_revmap(ks_pcie->legacy_irq_domain, offset); >> - dev_dbg(dev, ": irq: irq_offset %d, virq %d\n", offset, virq); >> - generic_handle_irq(virq); >> - } >> + virq = irq_linear_revmap(ks_pcie->legacy_irq_domain, offset); >> + dev_dbg(dev, ": irq: irq_offset %d, virq %d\n", offset, virq); >> + generic_handle_irq(virq); >> >> /* EOI the INTx interrupt */ >> ks_pcie_app_writel(ks_pcie, IRQ_EOI, offset); >> @@ -607,8 +602,9 @@ static void ks_pcie_legacy_irq_handler(struct irq_desc *desc) >> struct keystone_pcie *ks_pcie = irq_desc_get_handler_data(desc); >> struct dw_pcie *pci = ks_pcie->pci; >> struct device *dev = pci->dev; >> - u32 irq_offset = irq - ks_pcie->legacy_host_irqs[0]; >> struct irq_chip *chip = irq_desc_get_chip(desc); >> + unsigned int irq_no; >> + u32 reg; >> >> dev_dbg(dev, ": Handling legacy irq %d\n", irq); >> >> @@ -618,7 +614,13 @@ static void ks_pcie_legacy_irq_handler(struct irq_desc *desc) >> * ack operation. >> */ >> chained_irq_enter(chip, desc); >> - ks_pcie_handle_legacy_irq(ks_pcie, irq_offset); >> + for (irq_no = 0; irq_no < PCI_NUM_INTX; irq_no++) { > > I understand the aim of this code but now on platforms where there > is a 1:1 relationship between Linux IRQ and INTX this loop has > steps carried out for nothing. > > If I understand the code correctly what this code does is force > looping over INTX status regs regardless of what linux IRQ number was > actually active. right. This driver is used by 2 platforms K2G and AM654 (The patches are there on the list). K2G has 4 interrupt lines for each of the 4 legacy interrups while AM654 has a single interrupt line. One of the purpose of this patch is to have a single legacy interrupt handler for both K2G and AM654. > > You could do something faster by creating a matrix LinuxIRQ x INTx to > detect what INTx status register should actually be checked. > > This seems overkill to me but it is not that complicated to implement > and may clarify the code (and avoid reading up to three registers for > nothing on the IRQ code path, which can make things faster too). Agreed. But that's not possible for AM654 which has a single interrupt line and all the registers has to be read to identify the interrupt source. Thanks Kishon