From patchwork Wed Mar 26 21:42:59 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jason Gunthorpe X-Patchwork-Id: 3895451 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id CBAA19F2E8 for ; Wed, 26 Mar 2014 21:43:37 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D9B4220123 for ; Wed, 26 Mar 2014 21:43:36 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BA37920221 for ; Wed, 26 Mar 2014 21:43:35 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WSvbf-0001DO-Ua; Wed, 26 Mar 2014 21:43:32 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WSvbd-0004nW-8C; Wed, 26 Mar 2014 21:43:29 +0000 Received: from quartz.orcorp.ca ([184.70.90.242]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WSvba-0004mx-3f for linux-arm-kernel@lists.infradead.org; Wed, 26 Mar 2014 21:43:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=obsidianresearch.com; s=rsa1; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=NpzxMQmOVQFgYwWiy97YYM747BfH/lIUCfpo8jUAJlE=; b=DDyOozEGp1Wtb/YK60USc07QuA1NdR/0PM6jVqGRQsna5WjnJ9Gnh1SXTgqsSUgeEyg7rNfZWvRQx1ofju+bhbD4KW9jYGk4oL7AbRpZshoxFhUvGW6w0v2Nc2t9OYA05N6SIKY58S0IWyTcEesJB5UlBuAU812wVuBWN7jpNCQ=; Received: from [10.0.0.161] (helo=jggl.edm.orcorp.ca) by quartz.orcorp.ca with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WSvb9-0002Qv-Hq; Wed, 26 Mar 2014 15:42:59 -0600 Received: from jgg by jggl.edm.orcorp.ca with local (Exim 4.80) (envelope-from ) id 1WSvb9-0006mQ-5D; Wed, 26 Mar 2014 15:42:59 -0600 Date: Wed, 26 Mar 2014 15:42:59 -0600 From: Jason Gunthorpe To: Neil Greatorex Subject: Re: Intel I350 mini-PCIe card (igb) on Mirabox (mvebu / Armada 370) Message-ID: <20140326214259.GA12330@obsidianresearch.com> References: <20140325202249.GA10378@obsidianresearch.com> <20140325213638.5aba54b6@skate> <20140325222404.GC14718@obsidianresearch.com> <20140325223510.GD14718@obsidianresearch.com> <20140326201243.GA1536@obsidianresearch.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Broken-Reverse-DNS: no host name found for IP address 10.0.0.161 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140326_174326_278282_5722BA66 X-CRM114-Status: GOOD ( 18.72 ) X-Spam-Score: -2.0 (--) Cc: Thomas Petazzoni , Bjorn Helgaas , Jason Cooper , linux-arm-kernel , Willy Tarreau X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Mar 26, 2014 at 08:34:19PM +0000, Neil Greatorex wrote: > Thanks. Here's the relevant output with that patch: > > [ 0.135772] mvebu-pcie pcie-controller.3: ICR is 0 > [ 0.160889] mvebu-pcie pcie-controller.3: Vendor ID is ffffffff > [ 0.160897] mvebu-pcie pcie-controller.3: ICR is 800200 > [ 1.170215] mvebu-pcie pcie-controller.3: Try 2: Vendor ID is 15218086 > [ 1.170228] mvebu-pcie pcie-controller.3: ICR is 0 Okay, this looks better.. Thomas: Can you verify the decoding of the ICR register (offset 0x1900)? My Kirkwood manual says 0x800200 is 'Non-Fatal Error Detected' and 'Link Failure Indication' - the latter seems very strange. Could there be a doc error or change in the 370 version? I checked on my board here with the link down and I get: mvebu-pcie pex.1: Link is 0 mvebu-pcie pex.1: ICR is 0 mvebu-pcie pex.1: Vendor ID is ffffffff mvebu-pcie pex.1: ICR is 201 Which makes sense - NF Error + Tx while in Link down Error. In any event, lets try this. From 859a60617e050c51dc6bb83b2ed745d38a029b0d Mon Sep 17 00:00:00 2001 From: Jason Gunthorpe Date: Wed, 26 Mar 2014 15:38:44 -0600 Subject: [PATCH] PCI: mvebu - Repeat the ID read if there is a CRS reply Some PCI-E peers take a long time before they will respond to config transactions. In this case the spec says they should return a CRS status in the configuration read completion and the host should retry. mvebu docs say it sets a bit in the interrupt cause register when CRS is received. In-circuit testing with a 8086:1521 NIC suggests this might not be true, so we also monitor the non-fatal error bit, which does get set. Signed-off-by: Jason Gunthorpe --- drivers/pci/host/pci-mvebu.c | 50 ++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 46 insertions(+), 4 deletions(-) diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c index b8f2fc9..789cdb2 100644 --- a/drivers/pci/host/pci-mvebu.c +++ b/drivers/pci/host/pci-mvebu.c @@ -49,6 +49,10 @@ PCIE_CONF_FUNC(PCI_FUNC(devfn)) | PCIE_CONF_REG(where) | \ PCIE_CONF_ADDR_EN) #define PCIE_CONF_DATA_OFF 0x18fc +#define PCIE_ICR 0x1900 +#define PCIE_ICR_TX_IN_DOWN BIT(0) +#define PCIE_ICR_NFERR_DET BIT(9) +#define PCIE_ICR_CRS BIT(19) #define PCIE_MASK_OFF 0x1910 #define PCIE_MASK_ENABLE_INTS 0x0f000000 #define PCIE_CTRL_OFF 0x1a00 @@ -256,10 +260,44 @@ static int mvebu_pcie_hw_rd_conf(struct mvebu_pcie_port *port, struct pci_bus *bus, u32 devfn, int where, int size, u32 *val) { - mvebu_writel(port, PCIE_CONF_ADDR(bus->number, devfn, where), - PCIE_CONF_ADDR_OFF); - - *val = mvebu_readl(port, PCIE_CONF_DATA_OFF); + unsigned int tries = 0; + + while (1) { + if (where == 0) + mvebu_writel(port, ~(PCIE_ICR_TX_IN_DOWN | + PCIE_ICR_NFERR_DET | PCIE_ICR_CRS), + PCIE_ICR); + + mvebu_writel(port, PCIE_CONF_ADDR(bus->number, devfn, where), + PCIE_CONF_ADDR_OFF); + + *val = mvebu_readl(port, PCIE_CONF_DATA_OFF); + + if (where == 0) { + u32 icr = mvebu_readl(port, PCIE_ICR); + if (icr & PCIE_ICR_TX_IN_DOWN) + goto err_out; + + /* + * Implement Configuration Request Retry. If the + * configuration requst for the ID fails with a CRS or + * Non-Fatal status we try again for 100 ms. NFERR_DET + * is checked too, because CRS doesn't seem + * reliable */ + if (icr & (PCIE_ICR_NFERR_DET | PCIE_ICR_CRS)) { + if (tries >= 100) + goto err_out; + mdelay(1); + tries++; + continue; + } + } + break; + } + if (tries != 0) + dev_info(&port->pcie->pdev->dev, + "Port %u repeated ID read %u times\n", port->port, + tries); if (size == 1) *val = (*val >> (8 * (where & 3))) & 0xff; @@ -267,6 +305,10 @@ static int mvebu_pcie_hw_rd_conf(struct mvebu_pcie_port *port, *val = (*val >> (8 * (where & 3))) & 0xffff; return PCIBIOS_SUCCESSFUL; + +err_out: + *val = 0xffffffff; + return PCIBIOS_DEVICE_NOT_FOUND; } static int mvebu_pcie_hw_wr_conf(struct mvebu_pcie_port *port,