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=-4.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS,T_DKIMWL_WL_HIGH 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 88745C04AB2 for ; Thu, 9 May 2019 20:54:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 59ABB2177B for ; Thu, 9 May 2019 20:54:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557435258; bh=GW9NTiiQst8Up3h/AKS7pHiiiO/VAemperAGodxUfmk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=H3lPkGKNWtg1/bwYdBC5IRuWYh7UsXKF63pknnVIcaQROxGutd3X/9TkZuwDstB3L oHOLWtzAbxTR090GN7at5OnFAaE6A77TPQ9Oa0t9w8TVT+yA+TL6PL69WJFoZ5IDL1 PcSHO1wxmsBYr6njEy5hDv0pQXiDx+CViamaAmmY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726809AbfEIUyR (ORCPT ); Thu, 9 May 2019 16:54:17 -0400 Received: from mail-ot1-f65.google.com ([209.85.210.65]:32876 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725992AbfEIUyR (ORCPT ); Thu, 9 May 2019 16:54:17 -0400 Received: by mail-ot1-f65.google.com with SMTP id 66so3641690otq.0; Thu, 09 May 2019 13:54:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=60ekcbJtI6yZwQK328DWx4KfVWdYhF9HdCOSd8tn+fc=; b=ntelopzQTQrtkSmCCmZCZMD6l5CqgGHbAxhvzNBMvS6Se7xG6G99dDg9dKcUKA+0jW BRQ9E3yijsTo6BVzs+VYPMMgyp8zgWsn2KI7diBKOXuKXvK5c4M+MnKnv+bSog/s6VRg HaTCWtqls2JZz1J5bfmL0kHb9hQP/700HzZGhLQ+7NnzTPVBlI6fDfe++On9PZDu4N8N qLk1Ss07An/fm7in+zkCOJbxldQFOZGEm3YpgDwMK8c2D19Ov/0/yLoZ1OnfX5dDkigN q7cNncFMigEVVEu0lbrbGfYDxvPvwBSpcuUye/jg8IU0KJ20XVzfYvr+2W1SgufH3/xc 5apQ== X-Gm-Message-State: APjAAAWR9YnQYsRUM+EbiwTZZ2vsw+FRY7luU58Svjl6ai9pedopMDFJ X+Chj5ZcwNGmzr8AhfarqtZD4AzXEfWqN4D9Yi+VVAWT X-Google-Smtp-Source: APXvYqxd9HcbPWkz6t/Wpszcx4IS7BBEVuQ1Dmtlk6ndVnBj5wsJIJBWBYXfRyX1i+OvDo1jfPVbVdUN317opZrbVcA= X-Received: by 2002:a9d:4c86:: with SMTP id m6mr4219435otf.168.1557435256055; Thu, 09 May 2019 13:54:16 -0700 (PDT) MIME-Version: 1.0 References: <20190509061237.GA15229@lst.de> <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> In-Reply-To: <20190509192807.GB9675@localhost.localdomain> From: "Rafael J. Wysocki" Date: Thu, 9 May 2019 22:54:04 +0200 Message-ID: Subject: Re: [PATCH] nvme-pci: Use non-operational power state instead of D3 on Suspend-to-Idle To: Keith Busch Cc: Mario Limonciello , Kai-Heng Feng , Christoph Hellwig , Jens Axboe , Sagi Grimberg , "Rafael J. Wysocki" , Linux PM , Rafael Wysocki , Linux Kernel Mailing List , linux-nvme , Keith Busch Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 9, 2019 at 9:33 PM Keith Busch wrote: > > On Thu, May 09, 2019 at 06:57:34PM +0000, Mario.Limonciello@dell.com wrote: > > No, current Windows versions don't transition to D3 with inbox NVME driver. > > You're correct, it's explicit state transitions even if APST was enabled > > (as this patch is currently doing as well). > > The proposed patch does too much, and your resume latency will be worse > off for doing an unnecessary controller reset. > > The following should be all that's needed if the device is spec > compliant. The resume part isn't necessary if npss is non-operational, but > we're not saving that info, and it shouldn't hurt to be explicit anyway. > > I don't have any PS capable devices, so this is just compile tested. > > --- > diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c > index 6265d9225ec8..ce8b9bc949b9 100644 > --- a/drivers/nvme/host/core.c > +++ b/drivers/nvme/host/core.c > @@ -1132,6 +1132,22 @@ static int nvme_set_features(struct nvme_ctrl *dev, unsigned fid, unsigned dword > return ret; > } > > +int nvme_set_power(struct nvme_ctrl *ctrl, unsigned npss) > +{ > + int ret; > + > + mutex_lock(&ctrl->scan_lock); > + nvme_start_freeze(ctrl); > + nvme_wait_freeze(ctrl); > + ret = nvme_set_features(ctrl, NVME_FEAT_POWER_MGMT, npss, NULL, 0, > + NULL); > + nvme_unfreeze(ctrl); > + mutex_unlock(&ctrl->scan_lock); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(nvme_set_power); > + > int nvme_set_queue_count(struct nvme_ctrl *ctrl, int *count) > { > u32 q_count = (*count - 1) | ((*count - 1) << 16); > diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h > index 527d64545023..f2be6aad9804 100644 > --- a/drivers/nvme/host/nvme.h > +++ b/drivers/nvme/host/nvme.h > @@ -459,6 +459,7 @@ int __nvme_submit_sync_cmd(struct request_queue *q, struct nvme_command *cmd, > unsigned timeout, int qid, int at_head, > blk_mq_req_flags_t flags, bool poll); > int nvme_set_queue_count(struct nvme_ctrl *ctrl, int *count); > +int nvme_set_power(struct nvme_ctrl *ctrl, unsigned npss); > void nvme_stop_keep_alive(struct nvme_ctrl *ctrl); > int nvme_reset_ctrl(struct nvme_ctrl *ctrl); > int nvme_reset_ctrl_sync(struct nvme_ctrl *ctrl); > diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c > index a90cf5d63aac..2c4154cb4e79 100644 > --- a/drivers/nvme/host/pci.c > +++ b/drivers/nvme/host/pci.c > @@ -18,6 +18,7 @@ > #include > #include > #include > +#include > #include > #include > #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); > nvme_dev_disable(ndev, true); > return 0; > } > @@ -2860,6 +2863,8 @@ static int nvme_resume(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, 0); > nvme_reset_ctrl(&ndev->ctrl); > return 0; > } The rest of the patch LGTM.