From patchwork Wed Nov 2 09:26:55 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Koehrer Mathias (ETAS/EES-SL)" X-Patchwork-Id: 9408851 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 0A6DF601C2 for ; Wed, 2 Nov 2016 09:27:11 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E507229EC7 for ; Wed, 2 Nov 2016 09:27:10 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D9BAA29FB6; Wed, 2 Nov 2016 09:27:10 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6ADAE29EC7 for ; Wed, 2 Nov 2016 09:27:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751202AbcKBJ1G convert rfc822-to-8bit (ORCPT ); Wed, 2 Nov 2016 05:27:06 -0400 Received: from smtp6-v.fe.bosch.de ([139.15.237.11]:13809 "EHLO smtp6-v.fe.bosch.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750762AbcKBJ1F (ORCPT ); Wed, 2 Nov 2016 05:27:05 -0400 Received: from vsmta13.fe.internet.bosch.com (unknown [10.4.98.53]) by imta24.fe.bosch.de (Postfix) with ESMTP id D1C82D8024C; Wed, 2 Nov 2016 10:26:57 +0100 (CET) Received: from FE-MBX1011.de.bosch.com (vsgw23.fe.internet.bosch.com [10.4.98.23]) by vsmta13.fe.internet.bosch.com (Postfix) with ESMTP id 540412E40288; Wed, 2 Nov 2016 10:26:57 +0100 (CET) Received: from FE-MBX1012.de.bosch.com (10.3.230.70) by FE-MBX1011.de.bosch.com (10.3.230.69) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 2 Nov 2016 10:26:56 +0100 Received: from FE-MBX1012.de.bosch.com ([fe80::310c:6b49:1d6e:47a]) by FE-MBX1012.de.bosch.com ([fe80::310c:6b49:1d6e:47a%16]) with mapi id 15.00.1178.000; Wed, 2 Nov 2016 10:26:56 +0100 From: "Koehrer Mathias (ETAS/ESW5)" To: "linux-pci@vger.kernel.org" , Bjorn Helgaas , Bjorn Helgaas CC: Matthew Garrett , Julia Cartwright , Sebastian Andrzej Siewior Subject: [PATCH] Force to clear ASPM bits if CONFIG_PCIEASPM_PERFORMANCE is set Thread-Topic: [PATCH] Force to clear ASPM bits if CONFIG_PCIEASPM_PERFORMANCE is set Thread-Index: AdI06pf3Nymt003HQOy04m7ouP65+w== Date: Wed, 2 Nov 2016 09:26:55 +0000 Message-ID: <95e1fc6e84cf42e094d4a8478c37b18e@FE-MBX1012.de.bosch.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.162.35] MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22672.006 X-TMASE-MatchedRID: S4vihqueKciSKJETMovNaLCvlllU7Dl18lW420oy1gzBUsfdTKF6f4c7 DaU6vSPussCzF9uEX4QAFr/3c/MhzBNj8dEIVpt0Ee5D10MltLaEQiKo28GuY/WAXs8IQX1uBuq sMb/2uO4RydLpNqLuGiAicRj+5FEp8d2M04iWy/KrfZ+usyeESECrr/LkAQ46auHKE5Laxl+9vj 7fPWp7rpeQho4HSktcri+nqSEhIIScNVaNevidseKXavbHY/C1UrQk40lSPY5rRM6wvXgDaaF9h GJcIMF34vM1YF6AJbY65tgsJWcFUXnN0DN7HnFm6Z/Y7hdN5DrYUS3GeBC7ECOf2LgxSHFX/aCN VTE9w7u5DQkhPOLoue0GBznh1/IpQ//LDhMVOas8BLLA3lZvjco+h7MTDcOE Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On systems that have PCIe ASPM support in the BIOS enabled the commit 387d37577fdd05e9472c20885464c2a53b3c945f may lead to the situation that accesses to registers of enabled PCIe devices are extremely slow. This happens if the ACPI FADT declares incorrectly that the system doesn't support PCIe ASPM even if this is enabled in the BIOS. In this case the function pcie_no_aspm() will be called. However this sets the aspm_policy to POLICY_DEFAULT even if CONFIG_PCIEASPM_PERFORMANCE has been configured. As result, the ASPM on a PCIe may still be set even if this is not expected. This happens e.g. on a HP workstation 800 G1 together with an Intel dual port Ethernet server adapter i350 plugged in. Whenever ASPM is enabled in the BIOS the access to the LAN registers are really slow (read access: slower than 20us). In this setup the LnkCap of the two LAN controllers and of the integrated PCIe switch is set to "ASPM L1 Enabled" even if the controller is configured to be up and running. There has been a lengthy discussion on this performance issue due to this issue on the linux-rt-users list: http://marc.info/?l=linux-rt-users&m=147454824515022&w=2 This patch solves this issue by forcing to disable ASPM if CONFIG_PCIEASPM_PERFORMANCE has been set. Signed-off-by: Mathias Koehrer --- drivers/pci/pcie/aspm.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Index: linux-4.8/drivers/pci/pcie/aspm.c =================================================================== --- linux-4.8.orig/drivers/pci/pcie/aspm.c +++ linux-4.8/drivers/pci/pcie/aspm.c @@ -79,10 +79,13 @@ static LIST_HEAD(link_list); #ifdef CONFIG_PCIEASPM_PERFORMANCE static int aspm_policy = POLICY_PERFORMANCE; +static int aspm_default_config_policy = POLICY_PERFORMANCE; #elif defined CONFIG_PCIEASPM_POWERSAVE static int aspm_policy = POLICY_POWERSAVE; +static int aspm_default_config_policy = POLICY_POWERSAFE; #else static int aspm_policy; +static int aspm_default_config_policy; #endif static const char *policy_str[] = { @@ -946,7 +949,7 @@ void pcie_no_aspm(void) * (b) prevent userspace from changing policy */ if (!aspm_force) { - aspm_policy = POLICY_DEFAULT; + aspm_policy = aspm_default_config_policy; aspm_disabled = 1; } }