From patchwork Thu May 14 07:05:54 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Koba Ko X-Patchwork-Id: 1289956 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 49N2dD36yPz9sSs; Thu, 14 May 2020 17:06:08 +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 1jZ7wS-0006H8-M7; Thu, 14 May 2020 07:06:04 +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 1jZ7wQ-0006GV-4D for kernel-team@lists.ubuntu.com; Thu, 14 May 2020 07:06:02 +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 1jZ7wP-0001Dz-HP for kernel-team@lists.ubuntu.com; Thu, 14 May 2020 07:06:01 +0000 Received: by mail-pg1-f200.google.com with SMTP id v1so1678731pgl.4 for ; Thu, 14 May 2020 00:06:01 -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=AEFwmXbtTxXOlSrWtUhtO3rfQu+cM6kUNrxR2+DbG+M=; b=F3t2Jbr/CK0I0zF4KzcLeRvRuc3cPP7wmiDpvivRmhGvJrrSJK+0X0Xg6GVp46/jua eHC0GK9mEH8wVZ3vZ1k6v1a11GLpvONMvu4AqbAehEeYj305oehijLjcEBk+mUc1Qclh 6DdJYV7CISHMRk0iXeX8Q6gGTthlpC2p7rwn3xW3hf0PF9kZ1MpKGd2fBo6SdOWbpqep oDWivMd5e/+tPs6lpQWEedxA01xtwg6lbWXZv6tc3WZM3XEW1JRNlbkHMUhbZ0ooyjeN z7FkXuF61mBkgpCwIibEdHN2qrF40W6wrPtkXXKB1rcYU3jiIaSzYX6qaWLFng/49yb5 BOgQ== X-Gm-Message-State: AOAM5318INHo5So6hWhzM/ymVvPs6pYRdoHkKdUyAntHUsKf5MbICnZf xvlJjG/FvzHYNvB7f3T0BUCWbXHo6Kek5WuPhBcyPpZqIUQNwuir+C5eiMT0ipPWdweU84akVbL 10mk2iOvsCC0XQA6x+xsg1G6I3grzD6AmWZ1ZoJVC0g== X-Received: by 2002:aa7:9589:: with SMTP id z9mr3027322pfj.247.1589439959672; Thu, 14 May 2020 00:05:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyL+Dg4G7d3cpyJ4Bcs+T+urxJjyGMSC7sT8jc/gSWILFA939ZbdT/o/H/jDGwzoTXXuVOvKQ== X-Received: by 2002:aa7:9589:: with SMTP id z9mr3027298pfj.247.1589439959233; Thu, 14 May 2020 00:05:59 -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 a7sm1463036pfg.157.2020.05.14.00.05.58 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 14 May 2020 00:05:58 -0700 (PDT) From: koba.ko@canonical.com To: kernel-team@lists.ubuntu.com Subject: [PATCH v5 1/1][SRU][OEM-5.6] UBUNTU: SAUCE: PCI: Do not use pcie_get_speed_cap() to determine when to start waiting Date: Thu, 14 May 2020 15:05:54 +0800 Message-Id: <20200514070554.17069-2-koba.ko@canonical.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200514070554.17069-1-koba.ko@canonical.com> References: <20200514070554.17069-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 d828ca835a98..ebe626ad1b79 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -4765,7 +4765,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 {