{"id":805235,"url":"http://patchwork.ozlabs.org/api/1.2/patches/805235/?format=json","web_url":"http://patchwork.ozlabs.org/project/linux-pci/patch/1503551066-23212-3-git-send-email-oza.oza@broadcom.com/","project":{"id":28,"url":"http://patchwork.ozlabs.org/api/1.2/projects/28/?format=json","name":"Linux PCI development","link_name":"linux-pci","list_id":"linux-pci.vger.kernel.org","list_email":"linux-pci@vger.kernel.org","web_url":null,"scm_url":null,"webscm_url":null,"list_archive_url":"","list_archive_url_format":"","commit_url_format":""},"msgid":"<1503551066-23212-3-git-send-email-oza.oza@broadcom.com>","list_archive_url":null,"date":"2017-08-24T05:04:25","name":"[v8,2/3] PCI: iproc: retry request when CRS returned from EP","commit_ref":null,"pull_url":null,"state":"accepted","archived":false,"hash":"057d2253c3bf1e25746d1b6ccb6ba303445b58a5","submitter":{"id":71219,"url":"http://patchwork.ozlabs.org/api/1.2/people/71219/?format=json","name":"Oza Pawandeep","email":"oza.oza@broadcom.com"},"delegate":null,"mbox":"http://patchwork.ozlabs.org/project/linux-pci/patch/1503551066-23212-3-git-send-email-oza.oza@broadcom.com/mbox/","series":[],"comments":"http://patchwork.ozlabs.org/api/patches/805235/comments/","check":"pending","checks":"http://patchwork.ozlabs.org/api/patches/805235/checks/","tags":{},"related":[],"headers":{"Return-Path":"<linux-pci-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-pci-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=broadcom.com header.i=@broadcom.com\n\theader.b=\"TjFkKrTz\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xdC0b2JzCz9s78\n\tfor <incoming@patchwork.ozlabs.org>;\n\tThu, 24 Aug 2017 15:05:19 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751278AbdHXFEt (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tThu, 24 Aug 2017 01:04:49 -0400","from mail-wm0-f51.google.com ([74.125.82.51]:34716 \"EHLO\n\tmail-wm0-f51.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751250AbdHXFEp (ORCPT\n\t<rfc822; linux-pci@vger.kernel.org>); Thu, 24 Aug 2017 01:04:45 -0400","by mail-wm0-f51.google.com with SMTP id a70so4081252wmd.1\n\tfor <linux-pci@vger.kernel.org>; Wed, 23 Aug 2017 22:04:45 -0700 (PDT)","from anjanavk-OptiPlex-7010.dhcp.avagotech.net ([192.19.237.250])\n\tby smtp.gmail.com with ESMTPSA id\n\tn67sm3602691wmi.43.2017.08.23.22.04.37\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);\n\tWed, 23 Aug 2017 22:04:43 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=broadcom.com; s=google;\n\th=from:to:subject:date:message-id:in-reply-to:references:mime-version\n\t:content-transfer-encoding;\n\tbh=uTLZFckPUE5Jocj2eC6mpTClJfhW6nJu+6sVZ08ZC7w=;\n\tb=TjFkKrTzO1vQotYgqMszgvIXEx5hrD94tTaUMNXTKqSmbj2Lq3Z9Io90vbKwB5P9n9\n\t1Y3NApR8Hw+qhMX7noaCqFMU7x72PA6VzMmD1FP7Xds/E8m8dc6tloqHVh0IE1iQrVsD\n\tMXMdh7GL4YMY/dXeW2GHKacBISyxHws2sIaTg=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:from:to:subject:date:message-id:in-reply-to\n\t:references:mime-version:content-transfer-encoding;\n\tbh=uTLZFckPUE5Jocj2eC6mpTClJfhW6nJu+6sVZ08ZC7w=;\n\tb=a3NYd4iiGGEteoTcOdH5a1pn4b4Zny+pyBUeTIUrd0ZZK+HLpAKKorYg8MaKDLyweO\n\t7FucpxbdZ++0aEew8F5uYY53geYJWYGUivElYfjeoI2i9W5GwOUNg4Fycgfoaw1SePNV\n\tWB6MgPxdqKfJkczHDYwNBRIVms6wS0KHLx0TPFJMHcssYKp5wDch9++o+cscNnOQlTVo\n\t2Ceg1K1cJG8FtyEmQ9I4zzE5Wb12rDDpSg8b2bUeeORCC44imiFkz1UbfJwisAk8St76\n\twu3pTjFXyQk/t7+6OVTtsUZDDMknFOflzFtt3FyYZc8WbXOd38igB77X5/v13l0Yjy4T\n\t4DsA==","X-Gm-Message-State":"AHYfb5iAXsKhN4/81Dj+XdsRWuHulIfogJia9pDW0gV4wQkej8La1UMm\n\tR5f3ucPp8v14kgjNGD6E5g==","X-Received":"by 10.28.45.20 with SMTP id t20mr3493486wmt.5.1503551084371;\n\tWed, 23 Aug 2017 22:04:44 -0700 (PDT)","From":"Oza Pawandeep <oza.oza@broadcom.com>","To":"Bjorn Helgaas <bhelgaas@google.com>, <helgaas@kernel.org>,\n\tRob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>,\n\tRay Jui <rjui@broadcom.com>, Scott Branden <sbranden@broadcom.com>,\n\tJon Mason <jonmason@broadcom.com>, bcm-kernel-feedback-list@broadcom.com,\n\tOza Pawandeep <oza.oza@broadcom.com>,\n\tAndy Gospodarek <gospo@broadcom.com>,\n\tlinux-pci@vger.kernel.org, devicetree@vger.kernel.org,\n\tlinux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,\n\tOza Pawandeep <oza.pawandeep@gmail.com>","Subject":"[PATCH v8 2/3] PCI: iproc: retry request when CRS returned from EP","Date":"Thu, 24 Aug 2017 10:34:25 +0530","Message-Id":"<1503551066-23212-3-git-send-email-oza.oza@broadcom.com>","X-Mailer":"git-send-email 1.9.1","In-Reply-To":"<1503551066-23212-1-git-send-email-oza.oza@broadcom.com>","References":"<1503551066-23212-1-git-send-email-oza.oza@broadcom.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"8bit","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-pci.vger.kernel.org>","X-Mailing-List":"linux-pci@vger.kernel.org"},"content":"PCIe spec r3.1, sec 2.3.2\nIf CRS software visibility is not enabled, the RC must reissue the\nconfig request as a new request.\n\n- If CRS software visibility is enabled,\n- for a config read of Vendor ID, the RC must return 0x0001 data\n- for all other config reads/writes, the RC must reissue the\n  request\n\niproc PCIe Controller spec:\n4.7.3.3. Retry Status On Configuration Cycle\nEndpoints are allowed to generate retry status on configuration\ncycles. In this case, the RC needs to re-issue the request. The IP\ndoes not handle this because the number of configuration cycles needed\nwill probably be less than the total number of non-posted operations\nneeded.\n\nWhen a retry status is received on the User RX interface for a\nconfiguration request that was sent on the User TX interface,\nit will be indicated with a completion with the CMPL_STATUS field set\nto 2=CRS, and the user will have to find the address and data values\nand send a new transaction on the User TX interface.\nWhen the internal configuration space returns a retry status during a\nconfiguration cycle (user_cscfg = 1) on the Command/Status interface,\nthe pcie_cscrs will assert with the pcie_csack signal to indicate the\nCRS status.\nWhen the CRS Software Visibility Enable register in the Root Control\nregister is enabled, the IP will return the data value to 0x0001 for\nthe Vendor ID value and 0xffff  (all 1’s) for the rest of the data in\nthe request for reads of offset 0 that return with CRS status.  This\nis true for both the User RX Interface and for the Command/Status\ninterface.  When CRS Software Visibility is enabled, the CMPL_STATUS\nfield of the completion on the User RX Interface will not be 2=CRS and\nthe pcie_cscrs signal will not assert on the Command/Status interface.\n\nPer PCIe r3.1, sec 2.3.2, config requests that receive completions\nwith Configuration Request Retry Status (CRS) should be reissued by\nthe hardware except reads of the Vendor ID when CRS Software\nVisibility is enabled.\n\nThis hardware never reissues configuration requests when it receives\nCRS completions.\nNote that, neither PCIe host bridge nor PCIe core re-issues the\nrequest for any configuration offset.\n\nFor config reads, this hardware returns CFG_RETRY_STATUS data when\nit receives a CRS completion for a config read, regardless of the\naddress of the read or the CRS Software Visibility Enable bit.\n\nThis patch implements iproc_pcie_config_read which gets called for\nStingray, if it receives a CRS completion, it retries reading it again.\nIn case of timeout, it returns 0xffffffff.\nFor other iproc based SOC, it falls back to PCI generic APIs.\n\nSigned-off-by: Oza Pawandeep <oza.oza@broadcom.com>","diff":"diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c\nindex 61d9be6..37f4adf 100644\n--- a/drivers/pci/host/pcie-iproc.c\n+++ b/drivers/pci/host/pcie-iproc.c\n@@ -68,6 +68,9 @@\n #define APB_ERR_EN_SHIFT             0\n #define APB_ERR_EN                   BIT(APB_ERR_EN_SHIFT)\n \n+#define CFG_RETRY_STATUS             0xffff0001\n+#define CFG_RETRY_STATUS_TIMEOUT_US  500000 /* 500 milli-seconds. */\n+\n /* derive the enum index of the outbound/inbound mapping registers */\n #define MAP_REG(base_reg, index)      ((base_reg) + (index) * 2)\n \n@@ -473,6 +476,64 @@ static void __iomem *iproc_pcie_map_ep_cfg_reg(struct iproc_pcie *pcie,\n \treturn (pcie->base + offset);\n }\n \n+static unsigned int iproc_pcie_cfg_retry(void __iomem *cfg_data_p)\n+{\n+\tint timeout = CFG_RETRY_STATUS_TIMEOUT_US;\n+\tunsigned int data;\n+\n+\t/*\n+\t * As per PCIe spec r3.1, sec 2.3.2, CRS Software\n+\t * Visibility only affects config read of the Vendor ID.\n+\t * For config write or any other config read the Root must\n+\t * automatically re-issue configuration request again as a\n+\t * new request.\n+\t *\n+\t * For config reads, this hardware returns CFG_RETRY_STATUS data when\n+\t * it receives a CRS completion for a config read, regardless of the\n+\t * address of the read or the CRS Software Visibility Enable bit. As a\n+\t * partial workaround for this, we retry in software any read that\n+\t * returns CFG_RETRY_STATUS.\n+\t */\n+\tdata = readl(cfg_data_p);\n+\twhile (data == CFG_RETRY_STATUS && timeout--) {\n+\t\tudelay(1);\n+\t\tdata = readl(cfg_data_p);\n+\t}\n+\n+\tif (data == CFG_RETRY_STATUS)\n+\t\tdata = 0xffffffff;\n+\n+\treturn data;\n+}\n+\n+static int iproc_pcie_config_read(struct pci_bus *bus, unsigned int devfn,\n+\t\t\t\t    int where, int size, u32 *val)\n+{\n+\tstruct iproc_pcie *pcie = iproc_data(bus);\n+\tunsigned int slot = PCI_SLOT(devfn);\n+\tunsigned int fn = PCI_FUNC(devfn);\n+\tunsigned int busno = bus->number;\n+\tvoid __iomem *cfg_data_p;\n+\tunsigned int data;\n+\n+\t/* root complex access. */\n+\tif (busno == 0)\n+\t\treturn pci_generic_config_read32(bus, devfn, where, size, val);\n+\n+\tcfg_data_p = iproc_pcie_map_ep_cfg_reg(pcie, busno, slot, fn, where);\n+\n+\tif (!cfg_data_p)\n+\t\treturn PCIBIOS_DEVICE_NOT_FOUND;\n+\n+\tdata = iproc_pcie_cfg_retry(cfg_data_p);\n+\n+\t*val = data;\n+\tif (size <= 2)\n+\t\t*val = (data >> (8 * (where & 3))) & ((1 << (size * 8)) - 1);\n+\n+\treturn PCIBIOS_SUCCESSFUL;\n+}\n+\n /**\n  * Note access to the configuration registers are protected at the higher layer\n  * by 'pci_lock' in drivers/pci/access.c\n@@ -567,8 +628,13 @@ static int iproc_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,\n \t\t\t\t    int where, int size, u32 *val)\n {\n \tint ret;\n+\tstruct iproc_pcie *pcie = iproc_data(bus);\n \n \tiproc_pcie_apb_err_disable(bus, true);\n+\tif (pcie->type == IPROC_PCIE_PAXB_V2)\n+\t\tret = iproc_pcie_config_read(bus, devfn, where, size, val);\n+\telse\n+\t\tret = pci_generic_config_read32(bus, devfn, where, size, val);\n \tret = pci_generic_config_read32(bus, devfn, where, size, val);\n \tiproc_pcie_apb_err_disable(bus, false);\n \n","prefixes":["v8","2/3"]}