From patchwork Thu May 14 07:21:42 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Koba Ko X-Patchwork-Id: 1289958 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 49N2zQ6yZWz9sV7; Thu, 14 May 2020 17:21:54 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1jZ8Bj-0007NA-Gm; Thu, 14 May 2020 07:21:51 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jZ8Bg-0007Lo-1t for kernel-team@lists.ubuntu.com; Thu, 14 May 2020 07:21:48 +0000 Received: from mail-pg1-f200.google.com ([209.85.215.200]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jZ8Bf-0002TD-LC for kernel-team@lists.ubuntu.com; Thu, 14 May 2020 07:21:47 +0000 Received: by mail-pg1-f200.google.com with SMTP id j21so1681418pgh.12 for ; Thu, 14 May 2020 00:21:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references; bh=tWG91ISJ6PnjzYtgCjmr2vtZmbl2NO04NoYU3zuejbU=; b=lp13S/evQ+WZaM6Pmym6KtuQjpW1LVXPeYpFLjECYKu2FhBxTK6IXERpF3z+UphWOF nSXj/LCaZR249G96cZbt+AVgkBZ3rHI9k8UqeuntyVIC3AtbSpjppUGLxLpIHsTojIwR 68xevwH0kHfJAzDCRBOWtfgI7p1fhnZYrAHLtTf0IinlbKI5XDokNqBKZCOOkAXEzgOZ +SSmzcVMvYezwWjOn2zicwc0RpJhDD7NGBV7L9XvClTdUBRa1kicuV0zyNOGRc0R7UF8 viBfVKa58jeUrmYWDXCcwzaAc3OTD5GiwCueWoD20iip2ET/SQTIgo4hx4sCJeWo5rpe eZNA== X-Gm-Message-State: AOAM533fiJsmhSESu0ttxEO2wOLvRwd3CqquPghQoo4QsjNXmfMzPYEC dDfrG0gh/4NJq5ebecZtsB06YX53PtwZkd+LR3DbyA2ZT5JwvVIrZGGnVwG8a5fuh5HJg+F6k5K Xi6K0vjlGUEJy/OEJjr6qB8gNE2pj05u79+lNhgBCaA== X-Received: by 2002:a17:90a:2051:: with SMTP id n75mr13788806pjc.112.1589440906074; Thu, 14 May 2020 00:21:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyKgIQo977Ta8Gw49Qw0yQeRsuzLtiatHol6zg/HQqa4BzSS8CL5TxS08bMWQBgEc5AGZRgOw== X-Received: by 2002:a17:90a:2051:: with SMTP id n75mr13788788pjc.112.1589440905820; Thu, 14 May 2020 00:21:45 -0700 (PDT) Received: from canonical.com (114-43-71-139.dynamic-ip.hinet.net. [114.43.71.139]) by smtp.gmail.com with ESMTPSA id a2sm1501001pfi.208.2020.05.14.00.21.45 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 14 May 2020 00:21:45 -0700 (PDT) From: Koba Ko To: kernel-team@lists.ubuntu.com Subject: [PATCH v3 1/1][SRU][OEM-OSP1-B] UBUNTU: SAUCE: PCI: Do not use pcie_get_speed_cap() to determine when to start waiting Date: Thu, 14 May 2020 15:21:42 +0800 Message-Id: <20200514072142.18100-2-koba.ko@canonical.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200514072142.18100-1-koba.ko@canonical.com> References: <20200514072142.18100-1-koba.ko@canonical.com> X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Mika Westerberg BugLink: https://bugs.launchpad.net/bugs/1876844 Kai-Heng Feng reported that it takes long time (>1s) to resume Thunderbolt connected PCIe devices from both runtime suspend and system sleep (s2idle). These PCIe downstream ports the second link capability (PCI_EXP_LNKCAP2) announces support for speeds > 5 GT/s but it is then capped by the second link control (PCI_EXP_LNKCTL2) register to 2.5 GT/s. This possiblity was not considered in pci_bridge_wait_for_secondary_bus() so it ended up waiting for 1100 ms as these ports do not support active link layer reporting either. PCIe spec 5.0 section 6.6.1 mandates that we must wait minimum of 100 ms before sending configuration request to the device below, if the port does not support speeds > 5 GT/s, and if it does we first need to wait for the data link layer to become active before waiting for that 100 ms. PCIe spec 5.0 section 7.5.3.6 further says that all downstream ports that support speeds > 5 GT/s must support active link layer reporting so instead of looking for the speed we can check for the active link layer reporting capability and determine how to wait based on that (as they go hand in hand). Link: https://bugzilla.kernel.org/show_bug.cgi?id=206837 Reported-by: Kai-Heng Feng Tested-by: Kai-Heng Feng Signed-off-by: Mika Westerberg (cherry picked from https://lore.kernel.org/linux-pci/20200416083245.73957-1-mika.westerberg@linux.intel.com/) Signed-off-by: Koba Ko --- drivers/pci/pci.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 57acc8a26336..6b33b9f19ec8 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -4751,7 +4751,13 @@ void pci_bridge_wait_for_secondary_bus(struct pci_dev *dev) if (!pcie_downstream_port(dev)) return; - if (pcie_get_speed_cap(dev) <= PCIE_SPEED_5_0GT) { + /* + * Since PCIe spec mandates that all downstream ports that support + * speeds greater than 5 GT/s must support data link layer active + * reporting so we use that here to determine when the delay should + * be issued. + */ + if (!dev->link_active_reporting) { pci_dbg(dev, "waiting %d ms for downstream link\n", delay); msleep(delay); } else {