Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp648904ybj; Tue, 5 May 2020 05:32:26 -0700 (PDT) X-Google-Smtp-Source: APiQypKWz5xp6LxqvuKzEyVhq3KiOtNgpIBYByT8EAiVyzeMZKr1mcqaQgyXrxpq0F/Oyy6k2hjr X-Received: by 2002:a05:6402:154e:: with SMTP id p14mr621932edx.326.1588681946455; Tue, 05 May 2020 05:32:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588681946; cv=none; d=google.com; s=arc-20160816; b=Z6fyuzZHZxABxHTuRlkVgEF27yNj2HadQdSm5RnK9lC1Xi2M5F8Cir4rYQoL0WP/U+ k0ca4dWIBbzbPD0bXN9mJEEg6Vbe76SZuTHVNVMSKWBUFQxkNHtmtYrjyxhAt8YnOuw8 RQHj1Cry5m/sz7DmrzZrOhT0dYxWFrOCq8JrGz/lIy6OuHzQzRSRULQHxb3kNFwmvTn0 UPkjdMP5wU9YRi8YqBJmT8rs9jOBuVm/41TlyZcIrRvvg91qmeZibsUQdFqAzzS25xmK B9Gotk+ggGZszIDXyILBDgGJNQmWBsylS8lF4an/E+AmxL9pcrFKysppYfbqYMKCxC4H XlGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=Ln8zP4H+CvOpyJ6+hygzRGZZ2Hpd3NkpFUXld/GRprc=; b=UXGS1GH+tAuALHfdhbyfqloDrno8CjDm9mtc2dedoIHdAxotlGfCdJ6VYluexBxcQR +g+TZA2g2kov10K2/ZxXM8GC4lk1BlN831JT/5KcVXBfzOKQrzkJhOejJS0zjNA1Bnzw LI3EXrBENQv5wkU4sYncdmLZW8DvOEZgLl49764sjGFAL3f+2/AlIL0tiCbuUMifxYNK 8rrtcdPUvLUr7z3W/SBBR9foS1Lv38og4UtoZ0waYvvagQNvTyABuBdmqLByNd5F7Hwh PkjT+vCV80NVKWicD7OIUuonr10W6kVncshIrOt81IgsgKK46Ec0HtkatQB0ZJU84/+T rIvA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id os28si994651ejb.98.2020.05.05.05.32.01; Tue, 05 May 2020 05:32:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728875AbgEEM2U (ORCPT + 99 others); Tue, 5 May 2020 08:28:20 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:50795 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727090AbgEEM2T (ORCPT ); Tue, 5 May 2020 08:28:19 -0400 Received: from 61-220-137-37.hinet-ip.hinet.net ([61.220.137.37] helo=localhost) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jVwgB-0006Vr-46; Tue, 05 May 2020 12:28:07 +0000 From: Kai-Heng Feng To: bhelgaas@google.com Cc: Kai-Heng Feng , Heiner Kallweit , "Rafael J. Wysocki" , "David S. Miller" , Krzysztof Wilczynski , linux-pci@vger.kernel.org (open list:PCI SUBSYSTEM), linux-kernel@vger.kernel.org (open list) Subject: [PATCH v2] PCI/ASPM: Enable ASPM for root complex <-> bridge <-> bridge case Date: Tue, 5 May 2020 20:27:59 +0800 Message-Id: <20200505122801.12903-1-kai.heng.feng@canonical.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200504070259.6034-1-kai.heng.feng@canonical.com> References: <20200504070259.6034-1-kai.heng.feng@canonical.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The TI PCIe-to-PCI bridge prevents the Intel SoC from entering power state deeper than PC3 due to disabled ASPM, consumes lots of unnecessary power. On Windows ASPM L1 is enabled on the device and its upstream bridge, so it can make the Intel SoC reach PC8 or PC10 to save lots of power. Currently, ASPM is disabled if downstream has bridge function. It was introduced by commit 7d715a6c1ae5 ("PCI: add PCI Express ASPM support"). The commit introduced PCIe ASPM support, but didn't explain why ASPM needs to be in that case. So relax the condition a bit to let bridge which connects to root complex enables ASPM, instead of removing it completely, to avoid regression. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207571 Signed-off-by: Kai-Heng Feng --- drivers/pci/pcie/aspm.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c index 2378ed692534..af5e22d78101 100644 --- a/drivers/pci/pcie/aspm.c +++ b/drivers/pci/pcie/aspm.c @@ -629,13 +629,15 @@ static void pcie_aspm_cap_init(struct pcie_link_state *link, int blacklist) /* Setup initial capable state. Will be updated later */ link->aspm_capable = link->aspm_support; /* - * If the downstream component has pci bridge function, don't - * do ASPM for now. + * If upstream bridge isn't connected to root complex and the + * downstream component has pci bridge function, don't do ASPM for now. */ - list_for_each_entry(child, &linkbus->devices, bus_list) { - if (pci_pcie_type(child) == PCI_EXP_TYPE_PCI_BRIDGE) { - link->aspm_disable = ASPM_STATE_ALL; - break; + if (parent->bus->parent) { + list_for_each_entry(child, &linkbus->devices, bus_list) { + if (pci_pcie_type(child) == PCI_EXP_TYPE_PCI_BRIDGE) { + link->aspm_disable = ASPM_STATE_ALL; + break; + } } } -- 2.17.1