From patchwork Fri Feb 9 12:04:13 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vignesh Raghavendra X-Patchwork-Id: 10208879 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 387B260236 for ; Fri, 9 Feb 2018 12:04:53 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2DCC3297C7 for ; Fri, 9 Feb 2018 12:04:53 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 219D629811; Fri, 9 Feb 2018 12:04:53 +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=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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 CB0EB297C7 for ; Fri, 9 Feb 2018 12:04:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751093AbeBIMDy (ORCPT ); Fri, 9 Feb 2018 07:03:54 -0500 Received: from lelnx194.ext.ti.com ([198.47.27.80]:29054 "EHLO lelnx194.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751007AbeBIMDx (ORCPT ); Fri, 9 Feb 2018 07:03:53 -0500 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by lelnx194.ext.ti.com (8.15.1/8.15.1) with ESMTP id w19C3iRZ007098; Fri, 9 Feb 2018 06:03:44 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com; s=ti-com-17Q1; t=1518177824; bh=vsqnxa5Q75RHc6ObIEecG00omMG0QnxCfAEV09uB2vc=; h=From:To:CC:Subject:Date:In-Reply-To:References; b=lmL6oHq7IsltaztAWllBNpieo3JehUAKLqTpvvmXjlSQkFyVcw0h4Ic1ZTyUjMFcD m8e4+SbxFngtRb468xONk9DaorQ6J+4OmLUczTTv18r4lGZU+q7kPk/I2tKCoCECop GTvNt1GCIQ4KFgij970XAiSEOoW4uymB2KI3gKAg= Received: from DFLE106.ent.ti.com (dfle106.ent.ti.com [10.64.6.27]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id w19C3ilK022960; Fri, 9 Feb 2018 06:03:44 -0600 Received: from DFLE114.ent.ti.com (10.64.6.35) by DFLE106.ent.ti.com (10.64.6.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Fri, 9 Feb 2018 06:03:43 -0600 Received: from dflp33.itg.ti.com (10.64.6.16) by DFLE114.ent.ti.com (10.64.6.35) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1261.35 via Frontend Transport; Fri, 9 Feb 2018 06:03:44 -0600 Received: from a0132425.india.ti.com (ileax41-snat.itg.ti.com [10.172.224.153]) by dflp33.itg.ti.com (8.14.3/8.13.8) with ESMTP id w19C3bkp017802; Fri, 9 Feb 2018 06:03:41 -0600 From: Vignesh R To: Lorenzo Pieralisi , Jingoo Han , Joao Pinto CC: Kishon Vijay Abraham I , Bjorn Helgaas , Niklas Cassel , , , , Vignesh R Subject: [PATCH 1/3] Revert "PCI: dwc: Clear MSI interrupt status after it is handled, not before" Date: Fri, 9 Feb 2018 17:34:13 +0530 Message-ID: <20180209120415.17590-2-vigneshr@ti.com> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180209120415.17590-1-vigneshr@ti.com> References: <20180209120415.17590-1-vigneshr@ti.com> MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 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 Since commit 06e15e6883bed ("PCI: dwc: Clear MSI interrupt status after it is handled, not before"), MSI IRQ status in PCIE_MSI_INTR0_STATUS register is cleared after calling EP's IRQ handler. But, MSI IRQs in case of PCIe are bit like edge interrupts. If a another MSI IRQ is raised and the end of current EP's IRQ handler call but before clearing the MSI IRQ status in PCIE_MSI_INTR0_STATUS register then the new MSI IRQ is lost. This issue has been observed in case of USB-Ethernet adapter connected to PCIe USB card running iperf3 test. iperf3 client stalls after sometime as reported here[1]. This is because XHCI raises MSI IRQ at the end of its IRQ handler but before PCIe driver has cleared its status in PCIE_MSI_INTR0_STATUS register. Hence, the new IRQ is never registered by PCIe designware core. Since, XHCI does not raise any more IRQs until the previous one is handled, it leads to a stall in communication. Therefore driver should always clear the MSI IRQ status in PCIE_MSI_INTR0_STATUS before calling EP's IRQ handler. This make sure that DW PCIe core catches new IRQ raised during the call to EP's IRQ handler [1] https://lkml.kernel.org/r/BN6PR18MB124994D85EAC4B5B1AD5EC56866E0@BN6PR18MB1249.namprd18.prod.outlook.com Signed-off-by: Vignesh R Acked-by: Niklas Cassel --- drivers/pci/dwc/pcie-designware-host.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/dwc/pcie-designware-host.c b/drivers/pci/dwc/pcie-designware-host.c index 8de2d5c69b1d..c29cbcd430f4 100644 --- a/drivers/pci/dwc/pcie-designware-host.c +++ b/drivers/pci/dwc/pcie-designware-host.c @@ -68,9 +68,9 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp) while ((pos = find_next_bit((unsigned long *) &val, 32, pos)) != 32) { irq = irq_find_mapping(pp->irq_domain, i * 32 + pos); - generic_handle_irq(irq); dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_STATUS + i * 12, 4, 1 << pos); + generic_handle_irq(irq); pos++; } }