Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp3840712ioa; Tue, 26 Apr 2022 10:44:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzmKn+yvv9o18nZkIUkzx5I1B8qLNWacxdls+utl/D99EmBMkCsEjFgbvQmxGEv4depCaeQ X-Received: by 2002:a17:907:2da3:b0:6f3:6e74:67b0 with SMTP id gt35-20020a1709072da300b006f36e7467b0mr17343446ejc.766.1650995079910; Tue, 26 Apr 2022 10:44:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650995079; cv=none; d=google.com; s=arc-20160816; b=d1sSqCv0YZvOS+jvW688TwiJ04fLGuCsgvUz+m+DVqFkYkuL7dMp403Q4hcsmUM+yL mX4wo4PkBOTLQEB9GHDxHR6OIfPBt5AwxiRzt3XadAPmC0+3C6Rhc/ATMIl0aUExk9vu 9VCDF2+KQFW+DnfC6t7WVLRtFc5YjYDy2/TiUpHzwzqYGHAJNDA6Nu/2lit0hyykf/gg yEKBEXOJUsWSpr6aBvqtEG3skqeK5G55RLRL8SB/tyNk1wLy2I9qDCfH/l8tOpY6lAAB +o1U7tS5Ky2bJi6AfdsIgID5O2z1G5EBThFJVnuQZZyLFCAYQEfQqiw45JBKiPuWE8lv e1OQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:organization:references:in-reply-to:date:cc:to:reply-to :from:subject:message-id:dkim-signature; bh=HIDdG3oP29kipp6ApX84FKKwy/qOia5qTeV0HjEvxOk=; b=nM9+S3oYlQjw0oPd2p0OC//3ANk1Ty8wZKvxYW2/useccY9xLiTUS2Qr62AG1Vv3e3 s1ZL5Ihx79LvZmv90wv9hi8UJQDgQQzV+iUSKcDUUt/yXJE5NUxRUU5aHYcwgF7U2sOP Yrk6lhFaQ4H+WL3GO6FUs0WKouFP2W8NVPPUEt7CWCrb4m1o37SILqeHi0Ms26J5p5T4 7V8BTPr4Z/Ri8Eh9kjbOjk4CKQkIBgr3oym+JXu10UqLv/710Ut8D8V2EbUuDTZBwow/ C4H/TdjHdDxJvMO119mDCcaClSvJrOikAWAawEX1dLALygmu81SgmSnLWULOttUOhDVL gPuQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=OaTAtKKW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c9-20020a1709060fc900b006efd86f15d1si15151648ejk.822.2022.04.26.10.44.12; Tue, 26 Apr 2022 10:44:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=OaTAtKKW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244440AbiDYSgB (ORCPT + 99 others); Mon, 25 Apr 2022 14:36:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52738 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232253AbiDYSgA (ORCPT ); Mon, 25 Apr 2022 14:36:00 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B5CAEBEF; Mon, 25 Apr 2022 11:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650911575; x=1682447575; h=message-id:subject:from:reply-to:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=jmlGUQOKfZ1fEEUeDa+ZjhpmUMMaxIHAYo6P39XG2Tc=; b=OaTAtKKWsu0M7SZbE71kujYeNgCCCoi5MwKrNFsKeuUjG0/d67aH1JnE u47tfpk28HCmx/RldGmI4bBo42+sKv9it27jumXFi1zg0SZmd9NvqdayW GK79fiknh7KQThRik6NTW1v6FzrstV5KwkHq6CmrmH5BCLKeDi9D4YAic yVt2Iy+pfrxuUOP51+G2FDhpUbIRLdzeVmIYJJzOi2zK+S1hhvkqJ6ssJ sCXO08nfY3Mejw9Ws5wp1m6/7Lb8i332YeAN7HWwXWX000sy/i1VIeNZY F9gc3W4jBXQLBY/ndx3h3e1+yNqoWkLGJwwRS9QuZnsr2ydhlhhItmDjh Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10328"; a="262929321" X-IronPort-AV: E=Sophos;i="5.90,289,1643702400"; d="scan'208";a="262929321" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Apr 2022 11:32:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,289,1643702400"; d="scan'208";a="532246106" Received: from linux.intel.com ([10.54.29.200]) by orsmga006.jf.intel.com with ESMTP; 25 Apr 2022 11:32:55 -0700 Received: from jiunhong-mobl.amr.corp.intel.com (unknown [10.209.83.58]) by linux.intel.com (Postfix) with ESMTP id C001B5809EB; Mon, 25 Apr 2022 11:32:54 -0700 (PDT) Message-ID: <44ebf450aa3300e02aba6ec009d8bea20c0fc535.camel@linux.intel.com> Subject: Re: [PATCH v4 2/2] PCI/PM: Fix pci_pm_suspend_noirq() to disable PTM From: "David E. Box" Reply-To: david.e.box@linux.intel.com To: Bjorn Helgaas , "Jingar, Rajvi" Cc: "bhelgaas@google.com" , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , "Wysocki, Rafael J" , Kai-Heng Feng , "mika.westerberg@linux.intel.com" , "koba.ko@canonical.com" , "baolu.lu@linux.intel.com" , "sathyanarayanan.kuppuswamy@linux.intel.com" , Russell Currey , Oliver O'Halloran , "linuxppc-dev@lists.ozlabs.org" Date: Mon, 25 Apr 2022 11:32:54 -0700 In-Reply-To: <20220423150132.GA1552054@bhelgaas> References: <20220423150132.GA1552054@bhelgaas> Organization: David E. Box Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 2022-04-23 at 10:01 -0500, Bjorn Helgaas wrote: > On Sat, Apr 23, 2022 at 12:43:14AM +0000, Jingar, Rajvi wrote: > > > -----Original Message----- > > > From: Bjorn Helgaas > > > On Thu, Apr 14, 2022 at 07:54:02PM +0200, Rafael J. Wysocki wrote: > > > > On 3/25/2022 8:50 PM, Rajvi Jingar wrote: > > > > > For the PCIe devices (like nvme) that do not go into D3 state still > > > > > need to > > > > > disable PTM on PCIe root ports to allow the port to enter a lower- > > > > > power PM > > > > > state and the SoC to reach a lower-power idle state as a whole. Move > > > > > the > > > > > pci_disable_ptm() out of pci_prepare_to_sleep() as this code path is > > > > > not > > > > > followed for devices that do not go into D3. This patch fixes the > > > > > issue > > > > > seen on Dell XPS 9300 with Ice Lake CPU and Dell Precision 5530 with > > > > > Coffee > > > > > Lake CPU platforms to get improved residency in low power idle states. > > > > > > > > > > Fixes: a697f072f5da ("PCI: Disable PTM during suspend to save power") > > > > > Signed-off-by: Rajvi Jingar > > > > > Suggested-by: David E. Box > > > > > --- > > > > > drivers/pci/pci-driver.c | 10 ++++++++++ > > > > > drivers/pci/pci.c | 10 ---------- > > > > > 2 files changed, 10 insertions(+), 10 deletions(-) > > > > > > > > > > diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c > > > > > index 8b55a90126a2..ab733374a260 100644 > > > > > --- a/drivers/pci/pci-driver.c > > > > > +++ b/drivers/pci/pci-driver.c > > > > > @@ -847,6 +847,16 @@ static int pci_pm_suspend_noirq(struct device > > > > > *dev) > > > > > if (!pci_dev->state_saved) { > > > > > pci_save_state(pci_dev); > > > > > + /* > > > > > + * There are systems (for example, Intel mobile chips > > > > > since > > > Coffee > > > > > + * Lake) where the power drawn while suspended can be > > > significantly > > > > > + * reduced by disabling PTM on PCIe root ports as this > > > > > allows the > > > > > + * port to enter a lower-power PM state and the SoC to > > > > > reach a > > > > > + * lower-power idle state as a whole. > > > > > + */ > > > > > + if (pci_pcie_type(pci_dev) == PCI_EXP_TYPE_ROOT_PORT) > > > > > + pci_disable_ptm(pci_dev); > > > > > > Why is disabling PTM dependent on pci_dev->state_saved? The point of > > > this is to change the behavior of the device, and it seems like we > > > want to do that regardless of whether the driver has used > > > pci_save_state(). > > > > Because we use the saved state to restore PTM on the root port. > > And it's under this condition that the root port state gets saved. > > Yes, I understand that pci_restore_ptm_state() depends on a previous > call to pci_save_ptm_state(). > > The point I'm trying to make is that pci_disable_ptm() changes the > state of the device, and that state change should not depend on > whether the driver has used pci_save_state(). We do it here because D3 depends on whether the device state was saved by the driver. if (!pci_dev->state_saved) { pci_save_state(pci_dev); /* disable PTM here */ if (pci_power_manageable(pci_dev)) pci_prepare_to_sleep(pci_dev); } If we disable PTM before the check, we will have saved "PTM disabled" as the restore state. And we can't do it after the check as the device will be in D3. As to disabling PTM on all devices, I see no problem with this, but the reasoning is different. We disabled the root port PTM for power savings. David > > When we're putting a device into a low-power state, I think we want to > disable PTM *always*, no matter what the driver did. And I think we > want to do it for all devices, not just Root Ports. > > Bjorn