From patchwork Tue Mar 16 03:16:58 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 402344 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3493DC43332 for ; Tue, 16 Mar 2021 03:16:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 229E06508F for ; Tue, 16 Mar 2021 03:16:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234836AbhCPDPu (ORCPT ); Mon, 15 Mar 2021 23:15:50 -0400 Received: from mga05.intel.com ([192.55.52.43]:18301 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234798AbhCPDPi (ORCPT ); Mon, 15 Mar 2021 23:15:38 -0400 IronPort-SDR: 8YPgOtXkdJWVYMTF6cNo/EIIJAEFW4F0l++YKCvkt2vpaljteXgpTfC0db6VI9kRYt4E3m1lUt m4LDBVRTaiRg== X-IronPort-AV: E=McAfee;i="6000,8403,9924"; a="274233661" X-IronPort-AV: E=Sophos;i="5.81,251,1610438400"; d="scan'208";a="274233661" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2021 20:15:38 -0700 IronPort-SDR: GsP0e9nnlMyTFSiHva70pcPA6PYvQtjYvotkhJMuhd8U9Q0hs0seJVww+cC1SR33GiaxRQnLHh rJvop/ead5OA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,251,1610438400"; d="scan'208";a="601672904" Received: from anguy11-desk2.jf.intel.com ([10.166.244.147]) by fmsmga006.fm.intel.com with ESMTP; 15 Mar 2021 20:15:37 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org Cc: Chen Yu , netdev@vger.kernel.org, sassmann@redhat.com, anthony.l.nguyen@intel.com, kai.heng.feng@canonical.com, rjw@rjwysocki.net, len.brown@intel.com, todd.e.brandt@intel.com, sasha.neftin@intel.com, vitaly.lifshits@intel.com, Dvora Fuxbrumer Subject: [PATCH net-next v2 1/2] e1000e: Leverage direct_complete to speed up s2ram Date: Mon, 15 Mar 2021 20:16:58 -0700 Message-Id: <20210316031659.3695692-2-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20210316031659.3695692-1-anthony.l.nguyen@intel.com> References: <20210316031659.3695692-1-anthony.l.nguyen@intel.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Chen Yu The NIC is put in runtime suspend status when there is no cable connected. As a result, it is safe to keep non-wakeup NIC in runtime suspended during s2ram because the system does not rely on the NIC plug event nor WoL to wake up the system. Besides that, unlike the s2idle, s2ram does not need to manipulate S0ix settings during suspend. This patch introduces the .prepare() for e1000e so that if the NIC is runtime suspended the subsequent suspend/resume hooks will be skipped so as to speed up the s2ram. The pm core will check whether the NIC is a wake up device so there's no need to check it again in .prepare(). DPM_FLAG_SMART_PREPARE flag should be set during probe to ask the pci subsystem to honor the driver's prepare() result. Besides, the NIC remains runtime suspended after resumed from s2ram as there is no need to resume it. Tested on i7-2600K with 82579V NIC Before the patch: e1000e 0000:00:19.0: pci_pm_suspend+0x0/0x160 returned 0 after 225146 usecs e1000e 0000:00:19.0: pci_pm_resume+0x0/0x90 returned 0 after 140588 usecs After the patch: echo disabled > //sys/devices/pci0000\:00/0000\:00\:19.0/power/wakeup becomes 0 usecs because the hooks will be skipped. Suggested-by: Kai-Heng Feng Signed-off-by: Chen Yu Tested-by: Dvora Fuxbrumer Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/e1000e/netdev.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c index e9b82c209c2d..3eaae9a5a44e 100644 --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -25,6 +25,7 @@ #include #include #include +#include #include "e1000.h" @@ -6918,6 +6919,12 @@ static int __e1000_resume(struct pci_dev *pdev) return 0; } +static int e1000e_pm_prepare(struct device *dev) +{ + return pm_runtime_suspended(dev) && + pm_suspend_via_firmware(); +} + static __maybe_unused int e1000e_pm_suspend(struct device *dev) { struct net_device *netdev = pci_get_drvdata(to_pci_dev(dev)); @@ -7626,7 +7633,7 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent) e1000_print_device_info(adapter); - dev_pm_set_driver_flags(&pdev->dev, DPM_FLAG_NO_DIRECT_COMPLETE); + dev_pm_set_driver_flags(&pdev->dev, DPM_FLAG_SMART_PREPARE); if (pci_dev_run_wake(pdev) && hw->mac.type < e1000_pch_cnp) pm_runtime_put_noidle(&pdev->dev); @@ -7851,6 +7858,7 @@ MODULE_DEVICE_TABLE(pci, e1000_pci_tbl); static const struct dev_pm_ops e1000_pm_ops = { #ifdef CONFIG_PM_SLEEP + .prepare = e1000e_pm_prepare, .suspend = e1000e_pm_suspend, .resume = e1000e_pm_resume, .freeze = e1000e_pm_freeze, From patchwork Tue Mar 16 03:16:59 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 402345 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 09596C4332E for ; Tue, 16 Mar 2021 03:16:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C6B2165092 for ; Tue, 16 Mar 2021 03:16:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234818AbhCPDPs (ORCPT ); Mon, 15 Mar 2021 23:15:48 -0400 Received: from mga05.intel.com ([192.55.52.43]:18301 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234799AbhCPDPi (ORCPT ); Mon, 15 Mar 2021 23:15:38 -0400 IronPort-SDR: ddrZ4eN9j5MjRPWWwD+wS7ZguDr0J1TMsoNInJgOLdnPv56ws3BAmkaHe9iUOA7ByG8Z2YYDjY g2FRvLG973qw== X-IronPort-AV: E=McAfee;i="6000,8403,9924"; a="274233662" X-IronPort-AV: E=Sophos;i="5.81,251,1610438400"; d="scan'208";a="274233662" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2021 20:15:38 -0700 IronPort-SDR: odwXcWe3K6SfeJFNLA+0B1rZhV1UYr6MAFwe7UokE21s81ACPgPcoLlX2W4/0eK34U/zC14/wP dIOpDyQD3maw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,251,1610438400"; d="scan'208";a="601672906" Received: from anguy11-desk2.jf.intel.com ([10.166.244.147]) by fmsmga006.fm.intel.com with ESMTP; 15 Mar 2021 20:15:38 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org Cc: Chen Yu , netdev@vger.kernel.org, sassmann@redhat.com, anthony.l.nguyen@intel.com, kai.heng.feng@canonical.com, rjw@rjwysocki.net, len.brown@intel.com, todd.e.brandt@intel.com, sasha.neftin@intel.com, vitaly.lifshits@intel.com, Dvora Fuxbrumer Subject: [PATCH net-next v2 2/2] e1000e: Remove the runtime suspend restriction on CNP+ Date: Mon, 15 Mar 2021 20:16:59 -0700 Message-Id: <20210316031659.3695692-3-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20210316031659.3695692-1-anthony.l.nguyen@intel.com> References: <20210316031659.3695692-1-anthony.l.nguyen@intel.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Chen Yu Although there is platform issue of runtime suspend support on CNP, it would be more flexible to let the user decide whether to disable runtime or not because: 1. This can be done in userspace via echo on > /sys/devices/pci0000\:00/0000\:00\:1f.d/power/control 2. More and more NICs would support runtime suspend, disabling the runtime suspend on them by default would impact the validation. Only disable runtime suspend on CNP in case of any user space regression. Signed-off-by: Chen Yu Tested-by: Dvora Fuxbrumer Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/e1000e/netdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c index 3eaae9a5a44e..480f6712a3b6 100644 --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -7635,7 +7635,7 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent) dev_pm_set_driver_flags(&pdev->dev, DPM_FLAG_SMART_PREPARE); - if (pci_dev_run_wake(pdev) && hw->mac.type < e1000_pch_cnp) + if (pci_dev_run_wake(pdev) && hw->mac.type != e1000_pch_cnp) pm_runtime_put_noidle(&pdev->dev); return 0;