From mboxrd@z Thu Jan 1 00:00:00 1970 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=-2.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS,T_DKIMWL_WL_HIGH,USER_AGENT_MUTT 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 5EAF5C04AB2 for ; Thu, 9 May 2019 21:21:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 25C8F21744 for ; Thu, 9 May 2019 21:21:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557436904; bh=MtZGwZ/kepZ6jRVe08ecLLJkq/Gpq0bHIgh9dELdpOw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=lu+IMMxa+F8XyWeDCo0lT3LoHvB6MmQPK42GmHQfQm4+nv0d376fh4fr2WNuZOE7T T5swm82s9J/Sz220JSfkdwO1VUg6Gh4u++6EkxdMokIhK0gbB3bgr+qBZGiYzvMA6h yXGWarxFdSo7cKsKqDFDLyDRx/+XJfdYVklQM1vI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726939AbfEIVVn (ORCPT ); Thu, 9 May 2019 17:21:43 -0400 Received: from mga04.intel.com ([192.55.52.120]:14670 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726686AbfEIVVk (ORCPT ); Thu, 9 May 2019 17:21:40 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2019 14:21:39 -0700 X-ExtLoop1: 1 Received: from unknown (HELO localhost.localdomain) ([10.232.112.69]) by orsmga005.jf.intel.com with ESMTP; 09 May 2019 14:21:38 -0700 Date: Thu, 9 May 2019 15:16:09 -0600 From: Keith Busch To: "Rafael J. Wysocki" Cc: Mario Limonciello , Kai-Heng Feng , Christoph Hellwig , Jens Axboe , Sagi Grimberg , Linux PM , Rafael Wysocki , Linux Kernel Mailing List , linux-nvme , Keith Busch Subject: Re: [PATCH] nvme-pci: Use non-operational power state instead of D3 on Suspend-to-Idle Message-ID: <20190509211608.GC9675@localhost.localdomain> References: <064701C3-2BD4-4D93-891D-B7FBB5040FC4@canonical.com> <20190509095601.GA19041@lst.de> <225CF4F7-C8E1-4C66-B362-97E84596A54E@canonical.com> <20190509103142.GA19550@lst.de> <31b7d7959bf94c15a04bab0ced518444@AUSX13MPC101.AMER.DELL.COM> <20190509192807.GB9675@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 09, 2019 at 10:54:04PM +0200, Rafael J. Wysocki wrote: > On Thu, May 9, 2019 at 9:33 PM Keith Busch wrote: > > #include > > @@ -2851,6 +2852,8 @@ static int nvme_suspend(struct device *dev) > > struct pci_dev *pdev = to_pci_dev(dev); > > struct nvme_dev *ndev = pci_get_drvdata(pdev); > > > > + if (!pm_suspend_via_firmware()) > > + return nvme_set_power(&ndev->ctrl, ndev->ctrl.npss); > > You probably want to call pci_save_state(pdev) in the branch above to > prevent pci_pm_suspend_noirq() from calling pci_prepare_to_sleep() > going forward, so I would write this routine as > > if (pm_suspend_via_firmware()) { > nvme_dev_disable(ndev, true); > return 0; > } > > pci_save_state(pdev) > return nvme_set_power(&ndev->ctrl, ndev->ctrl.npss); Ah, good point. I'll make sure that's added and will wait to see hear if there's any other feedback. I am trying to test the paths by faking out PS capabilities, and have a question on how to force each: Running "rtcwake -m freeze ...", that takes the !pm_suspend_via_firmware() path as I expected. But trying to test the original path, I thought using "-m mem" would have been a suspend via firmware, but that is still returning false. Is that expected? I've only tried this on one platform so far, so might just be this particular one is missing a firmware capability.